Создание уникальных и непрозрачных идентификаторов пользователей в Google App Engine

Question

Я работаю над приложением, которое позволяет зарегистрированным пользователям создавать или загружать контент и позволяет анонимным пользователям просматривать этот контент и просматривать страницы зарегистрированных пользователей, чтобы найти этот контент - это очень похоже на то, как такой сайт, как Flickr, для Например, позволяет людям просматривать страницы своих пользователей.

Для этого мне нужен способ идентифицировать пользователя в анонимном HTTP-запросе GET. Пользователь должен иметь возможность набрать http://myapplication.com/browse/<userid>/<contentid> и перейти на нужную страницу - должен быть уникальным, но не должен быть похож на адрес электронной почты пользователя по соображениям конфиденциальности.

Через Google App Engine я могу получить адрес электронной почты, связанный с пользователем, но, как я уже сказал, я не хочу его использовать. Я могу предложить пользователям моего приложения выбрать уникальное имя пользователя при регистрации, но я бы хотел сделать это необязательным, если это вообще возможно, чтобы процесс регистрации был максимально коротким.

Другим вариантом является создание некоторого случайного файла cookie (GUID?) В процессе регистрации и использование его. Я не вижу очевидного способа гарантировать уникальность такого файла cookie без обращения к базе данных.

Есть ли способ, учитывая объект пользователя App Engine, получить уникальный идентификатор для этого объекта, который можно использовать таким образом?

Я ищу решение Python - я забыл, что GAE теперь также поддерживает Java. Тем не менее, я ожидаю, что методы будут одинаковыми, независимо от языка.

Answer 1

Ваше время безукоризненно: только вчера вышел новый выпуск SDK с поддержкой уникальных постоянных идентификаторов пользователя . Они соответствуют всем указанным вами критериям.

Answer 2

Я думаю, вы должны различать два типа пользователей:

1) пользователи, которые вошли в систему через учетные записи Google или уже зарегистрировались на вашем сайте с адресом электронной почты, не принадлежащим Google *

2) пользователи, которые открыли ваш сайт впервые и никоим образом не вошли в систему

Во втором случае я не вижу другого способа, кроме как генерировать некоторую случайную строку (например, с помощью uuid.uuid4() или из ключа cookie сеанса этого пользователя), поскольку анонимный пользователь не несет никакой уникальной информации с собой.

Для пользователей, которые вошли в систему, однако, у вас уже есть уникальный идентификатор - их адрес электронной почты. Я согласен с вашими вопросами конфиденциальности - вы не должны использовать его в качестве идентификатора. Вместо этого, как насчет генерации строки, которая кажется случайной, но фактически генерируется из адреса электронной почты? Хеш-функции идеально подходят для этой цели. Пример:

>>> import hashlib

>>> email = 'user@host.com'
>>> salt = 'SomeLongStringThatWillBeAppendedToEachEmail'

>>> key = hashlib.sha1('%s$%s' % (email, salt)).hexdigest()
>>> print key
f6cd3459f9a39c97635c652884b3e328f05be0f7

Поскольку hashlib.sha1 не является случайной функцией, но для данных возвращает всегда один и тот же результат, но доказано, что он практически необратим, вы можете смело представлять хешированный ключ на веб-сайте без ущерба для адреса электронной почты пользователя. Кроме того, вы можете смело предположить, что никакие два хэша различных электронных писем не будут одинаковыми (они могут быть, но вероятность этого очень, очень мала). Для получения дополнительной информации о функциях хеширования обратитесь к записи в Википедии .

Answer 3

Вы имеете в виду сеансовые куки ?

Попробуйте http://code.google.com/p/gaeutilities/

---

Что сказал DzinX. Единственный способ создать непрозрачный ключ, который может быть аутентифицирован без обращения к базе данных, - это использовать шифрование или криптографический хеш.

Дайте пользователю случайное число и зашифруйте его или зашифруйте с помощью закрытого ключа. Вы все еще рискуете (крошечным) риском коллизий, но вы можете избежать этого, касаясь базы данных при создании ключа, изменяя случайное число в случае коллизии. Убедитесь, что случайное число является криптографическим, и добавьте длинное случайное число на стороне сервера, чтобы предотвратить выбранные атаки открытым текстом.

В результате вы получите токен, такой как ключ Google Docs, в основном подпись, подтверждающую подлинность пользователя, которую можно проверить, не касаясь базы данных.

Однако, учитывая цену GAE и скорость bigtable, вам, вероятно, лучше использовать идентификатор сессии, если вы действительно не можете использовать собственную аутентификацию Google.