Génération ID d'utilisateur uniques et opaques dans Google App Engine

Question

Je travaille sur une application qui permet aux utilisateurs enregistrés de créer ou de contenu télécharger et permet aux utilisateurs anonymes de voir que le contenu et parcourir les pages des utilisateurs enregistrés pour trouver que le contenu - ce qui est très similaire à la façon dont un site comme Flickr, pour par exemple, permet aux gens de parcourir les pages de ses utilisateurs.

Pour ce faire, il me faut un moyen d'identifier l'utilisateur dans la requête HTTP GET anonyme. Un utilisateur doit être en mesure de taper http://myapplication.com/browse/<userid>/<contentid> et accéder à la page droite - doit être unique, mais ne doit pas être quelque chose comme l'adresse e-mail de l'utilisateur, pour des raisons de confidentialité.

Grâce à Google App Engine, je peux obtenir l'adresse e-mail associée à l'utilisateur, mais comme je l'ai dit, je ne veux pas l'utiliser. Je peux avoir des utilisateurs de ma demande de choisir un nom d'utilisateur unique lors de leur inscription, mais je voudrais faire que facultative, si possible, de sorte que le processus d'inscription est aussi courte que possible.

Une autre option est de générer des cookies au hasard (un GUID?) Pendant le processus d'enregistrement, et l'utiliser, je ne vois pas de façon évidente de garantir l'unicité d'un tel biscuit sans un voyage à la base de données.

Est-il possible, étant donné un objet utilisateur App Engine, d'obtenir un identifiant unique pour cet objet qui peut être utilisé de cette façon?

Je suis à la recherche d'une solution Python - j'ai oublié que GAE prend également en charge Java maintenant. Pourtant, j'attends les techniques soient similaires, quelle que soit la langue.

Answer 1

Votre timing est impeccable: Hier, une nouvelle version du SDK est sorti, avec prise en charge uniques, ID utilisateur permanent . Ils répondent à tous les critères spécifiés.

Answer 2

Je pense que vous devez établir une distinction entre deux types d'utilisateurs:

1) les utilisateurs qui se sont connectés via des comptes Google ou qui ont déjà enregistrés sur votre site avec une adresse e-mail non-Google

2) les utilisateurs qui ont ouvert votre site pour la première fois et ne sont pas connectés de quelque manière que

Pour le second cas, je ne vois pas d'autre moyen que de générer une chaîne aléatoire (par exemple via uuid.uuid4() ou de la clé de cookie de session de l'utilisateur), en tant qu'utilisateur anonyme ne porte pas d'information unique avec lui-même.

Pour les utilisateurs qui sont connectés, cependant, vous avez déjà un identifiant unique - leur adresse e-mail. Je suis d'accord avec vos problèmes de confidentialité - vous ne devriez pas l'utiliser comme un identifiant. Au lieu de cela, que diriez-vous générer une chaîne semble au hasard, mais est en fait produite à partir de l'adresse e-mail? fonctions sont parfaits pour Hachage cet effet. Exemple:

>>> import hashlib

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

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

hashlib.sha1 n'est pas une fonction aléatoire, mais pour les retours de données données toujours le même résultat, mais il est avéré être pratiquement irréversible, vous pouvez sans risque présenter la clé hachée sur le site sans compromettre l'adresse e-mail de l'utilisateur. Aussi, vous pouvez supposer que deux hash d'e-mails distincts seront les mêmes (ils peuvent être, mais la probabilité que cela se produise est très, très faible). Pour plus d'informations sur les fonctions de hachage, consultez entrée Wikipedia.

Answer 3

Voulez-vous dire cookies de session ?

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

---

Qu'est-ce que dit DzinX. La seule façon de créer une clé opaque qui peut être authentifié sans aller-retour de la base de données utilise le cryptage ou un hachage cryptographique.

Donner à l'utilisateur un nombre aléatoire et hachage ou chiffrer avec une clé privée. Vous courez toujours le (petit) risque de collisions, mais vous pouvez éviter cela en touchant la base de données sur la création clé, la modification du nombre aléatoire en cas de collision. Assurez-vous que le nombre aléatoire est cryptographique, et ajoutez un long côté serveur nombre aléatoire pour éviter les attaques choisies plaintext.

Vous allez finir avec un jeton comme la clé de Google Docs, essentiellement une signature prouvant l'utilisateur est authentifié, qui peut être vérifié sans toucher à la base de données.

Toutefois, étant donné le prix des GAE et la vitesse de BigTable, vous êtes probablement mieux d'utiliser un ID de session si vous ne pouvez vraiment pas utiliser l'authentification propre Google.