Создание уникальных и непрозрачных идентификаторов пользователей в 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 с поддержкой unique, permanent user IDs. Они соответствуют всем указанным вами критериям.

Answer 2

Возможно, вы имели в виду session cookies?

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

---

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

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

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

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

Answer 3

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

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 не является случайной функцией, но для данных возвращает данные всегда тот же результат, но она оказалась практически необратим, то можно смело представить хэшированного ключ на веб-сайте без ущерба для пользователя е -Почта Адрес. Кроме того, вы можете смело предположить, что никакие два хэша отдельных электронных писем не будут одинаковыми (они могут быть, но вероятность того, что это произойдет, очень, очень мало). Для получения дополнительной информации о хэш-функции см. the Wikipedia entry.