Generando ID de usuario únicos y opacos en Google App Engine

Question

Estoy trabajando en una aplicación que permite a los usuarios registrados crear o cargar contenido y permite a los usuarios anónimos ver ese contenido y explorar las páginas de los usuarios registrados para encontrar ese contenido. muy similar a cómo un sitio como Flickr, por ejemplo, permite a las personas navegar por las páginas de sus usuarios.

Para hacer esto, necesito una forma de identificar al usuario en la solicitud HTTP GET anónima. Un usuario debe ser capaz de escribir http://myapplication.com/browse/<userid>/<contentid> y llegar a la página correcta, debe ser único, pero no debe ser algo así como la dirección de correo electrónico del usuario, por razones de privacidad.

A través de Google App Engine, puedo obtener la dirección de correo electrónico asociada con el usuario, pero como dije, no quiero usar eso. Puedo hacer que los usuarios de mi aplicación elijan un nombre de usuario único cuando se registren, pero me gustaría que sea opcional, si es posible, para que el proceso de registro sea lo más breve posible.

Otra opción es generar alguna cookie aleatoria (¿un GUID?) Durante el proceso de registro, y usar eso, no veo una manera obvia de garantizar la singularidad de dicha cookie sin un viaje a la base de datos.

¿Hay alguna manera, dado un objeto de usuario de App Engine, de obtener un identificador único para ese objeto que se pueda usar de esta manera?

Estoy buscando una solución de Python - Olvidé que GAE también es compatible con Java ahora. Aún así, espero que las técnicas sean similares, independientemente del idioma.

Answer 1

Su sincronización es impecable: Ayer, salió una nueva versión del SDK, con soporte para unique, permanent user IDs. Cumplen con todos los criterios que especificó.

Answer 2

¿Quieres decir session cookies?

Trate http://code.google.com/p/gaeutilities/

---

Lo dijo DzinX. La única forma de crear una clave opaca que se puede autenticar sin un viaje de ida y vuelta a la base de datos es usando cifrado o un hash criptográfico.

Proporcione al usuario un número aleatorio y cópielo o cifrelo con una clave privada. Aún corre el (pequeño) riesgo de colisión, pero puede evitarlo tocando la base de datos en la creación de la clave, cambiando el número aleatorio en caso de una colisión. Asegúrese de que el número aleatorio sea criptográfico y agregue un número aleatorio largo del lado del servidor para evitar los ataques de texto plano elegidos.

Terminará con un token como la tecla Google Docs, básicamente una firma que acredite que el usuario está autenticado, lo que se puede verificar sin tocar la base de datos.

Sin embargo, dado el precio de GAE y la velocidad de bigtable, es mejor que uses una ID de sesión si realmente no puedes usar la autenticación de Google.

Answer 3

creo que debe distinguir entre dos tipos de usuarios:

1) los usuarios que han iniciado sesión en medio de las cuentas de Google o que ya se han registrado en su sitio con un Google no dirección de correo electrónico

2) usuarios que abrieron su sitio por primera vez y no iniciaron sesión de ninguna manera

Para el segundo caso, no veo otra manera que generar una cadena aleatoria (por ejemplo, a través de uuid.uuid4() o de la cookie de esta sesión del usuario clave), ya que un usuario anónimo no lleva consigo ninguna información exclusiva.

Para los usuarios que ya han iniciado sesión, sin embargo, usted ya tiene un identificador único: su dirección de correo electrónico. Estoy de acuerdo con sus inquietudes sobre privacidad: no debe usarlo como identificador. En cambio, ¿qué hay de generar una cadena que parece al azar, pero de hecho se genera a partir de la dirección de correo electrónico? Las funciones hash son perfectas para este propósito. Ejemplo:

>>> import hashlib 

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

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

Como hashlib.sha1 no es una función aleatoria, pero para las devoluciones de datos dado siempre el mismo resultado, pero se ha demostrado ser prácticamente irreversible, se puede presentar de forma segura la clave hash en el sitio web sin comprometer correo del usuario -Correo Electronico. Además, puede suponer con seguridad que no hay dos hashes de correos electrónicos distintos iguales (pueden serlo, pero la probabilidad de que suceda es muy, muy pequeña). Para obtener más información sobre las funciones hashing, consulte the Wikipedia entry.