Предоставление идентификаторов сущностей данных Google Datastore - PullRequest
2 голосов
/ 09 июля 2009

Сохраняется ли для предоставления идентификаторов сущностей данных, которые находятся в Google Datastore. Например, в моем коде у меня есть сущность с этим идентификатором:

@PrimaryKey
@Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY)
@Extension(vendorName="datanucleus", key="gae.encoded-pk", value="true")
private String id;

Идентификатор будет похож на это: agptZeERtzaWYvSQadLEgZDdRsUYRs

Может ли кто-нибудь извлечь из этой строки пароль, URL-адрес приложения и любую другую информацию? Что означает эта строка?

Ответы [ 3 ]

2 голосов
/ 15 июля 2009

Этот идентификатор объекта содержит идентификатор объекта, идентификатор приложения и имя класса объекта. Это просто закодированная строка. На самом деле никакой угрозы безопасности нет.

1 голос
/ 11 июля 2009

Вы можете использовать KeyFactory для преобразования в keytoString, stringToKey следующим образом URL Google App Engine :

идентификатор, который, как мне кажется, был уникальным для хранилища данных в Google App Engine.

Ключевые экземпляры могут быть преобразованы в и из кодированного строкового представления используя методы KeyFactory keyToString () и stringToKey ().

При использовании кодированных строк ключей вы может обеспечить доступ к объекту строка или числовой идентификатор с дополнительные поля.

Надеюсь, это поможет.

Tiger.

0 голосов
/ 18 августа 2009

Если вы перейдете к localhost: 4321 / _ah / admin, вы можете воспользоваться средством просмотра хранилища данных sdk, где вы увидите, что у каждого типа сущностей есть поле KEY и поле NAME / ID;

Независимо от того, используете ли вы long, String или Key в качестве @PrimaryKey, будет столбец ID / Name со строкой / номером и столбец KEY с закодированным ключом для указанного идентификатора. Как упоминалось в других статьях, эта кодировка хэширует {md5s, скорее всего}, идентификатор приложения appspot, полное имя класса объекта данных и все, что вы указываете как @ PrimaryKey.

Единственный раз, когда вам понадобится прямой доступ к этому полю, это если вам абсолютно все равно, как называются данные, {когда вам нужна ваша программа, чтобы найти их, но люди не будут искать их, угадывая слова в текстовое поле}, или когда вы ХОТИТЕ иметь несколько объектов одного типа и имени {возможно, с использованием версии int?}, вам следует использовать синтаксис закодированного ключа. И KEY, и ID присутствуют в БД, независимо от того, помещаете ли вы поле в свой класс. Использование синтаксиса закодированного ключа просто дает вам доступ к этому значению.

Кроме того, существует доступный бонус скорости для приложений, использующих закодированные ключи ... Существует только два типа запросов: SELECT * и SELECT _ _ key _ _ {пробелы, используемые для отображения двух _}. Для больших наборов данных в приложениях AJAX единственный эффективный способ разбивки данных на страницы состоит в том, чтобы выбрать все ключи, отправить их клиенту и попросить клиента запросить 0-> X записей, создать ссылки для других X-> Результаты Y и запросить сервер с первым набором закодированных ключей для получения полных данных, проанализировать ответ в симпатичные маленькие списки и избежать загрузки 397 объектов данных сервера, которые не являются полезными сразу.

Передача закодированных ключей вверх и вниз по проводам может занять немного большую полосу пропускания, чем не закодированные ключи {если только вы не так долго называетесь, как я!}; но он сокращает эти циклы ЦП на appengine, делает ваши квоты более счастливыми, а все приложения работают на долю чуть быстрее!

Этот ключ, даже если он каким-то образом не хэширован, будет отображать данные, настолько же чувствительные, как и все, что вы делаете с помощью PrimaryKey. Ваш пароль приложения не задействован, равно как и пароли пользователей в любой разумной модели данных. Единственная вещь, которая может {BIG может} утечь}, это адрес электронной почты пользователя, если вы используете предоставленный класс User для аутентификации, или имена классов, которые вы используете в своем источнике.

... По сути, может быть раскрыта только информация, уже имеющаяся в просмотре или запросе двух человек:

...