Generazione di ID utente univoci e opachi in Google App Engine

Question

Sto lavorando a un'applicazione che consente agli utenti registrati di creare o caricare contenuti, e consente agli utenti anonimi di visualizzare tali contenuti e consultare le pagine degli utenti registrati di trovare che il contenuto - questo è molto simile a come un sito come Flickr, per ad esempio, permette alle persone di navigare le pagine dei suoi utenti.

Per fare questo, ho bisogno di un modo per identificare l'utente nella richiesta HTTP GET anonima. Un utente dovrebbe essere in grado di digitare http://myapplication.com/browse/<userid>/<contentid> e arrivare alla giusta pagina - dovrebbe essere unico, ma non deve essere qualcosa come l'indirizzo di posta elettronica dell'utente, per motivi di privacy.

Con Google App Engine, posso ottenere l'indirizzo email associato con l'utente, ma come ho detto, non voglio usare quella. Posso avere gli utenti della mia applicazione scegliere un nome utente univoco al momento della registrazione, ma vorrei fare quella facoltativa, se possibile, in modo che il processo di registrazione è più breve possibile.

Un'altra opzione è quella di generare qualche biscotto casuale (un GUID?) Durante il processo di registrazione, e l'uso che, non vedo un modo ovvio di garantire l'unicità di tale biscotto senza una visita al database.

C'è un modo, dato un oggetto utente App Engine, di ottenere un identificatore univoco per l'oggetto che può essere utilizzato in questo modo?

Sto cercando una soluzione Python - Ho dimenticato che GAE supporta anche Java ora. Eppure, mi aspetto che le tecniche per essere simili, indipendentemente dalla lingua.

Answer 1

Il tuo tempismo è impeccabile: Proprio ieri, una nuova versione del SDK è uscito, con il supporto per unici, ID utente permanenti . Si incontrano tutti i criteri specificati.

Answer 2

Credo che si dovrebbe distinguere tra due tipi di utenti:

1) gli utenti che hanno effettuato l'accesso tramite account Google o che sono già registrati sul tuo sito con un google non l'indirizzo e-mail

2) gli utenti che ha aperto il sito per la prima volta e non sono connessi in qualsiasi modo

Per il secondo caso, non vedo altra via che per generare qualche stringa casuale (per esempio tramite uuid.uuid4() oppure da chiave di sessione cookie di questo utente), come un utente anonimo non porta alcuna informazione unico con se stesso.

Per gli utenti che hanno effettuato l'accesso, tuttavia, è già un identificatore univoco - il loro indirizzo di posta elettronica. Sono d'accordo con i tuoi problemi di privacy - non si deve usare come un identificatore. Invece, che ne dici di generare una stringa che sembra casuale, ma è in realtà generato dal indirizzo e-mail? funzioni di hashing sono perfetti per questo scopo. Esempio:

>>> import hashlib

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

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

Come hashlib.sha1 non è una funzione casuale, ma per determinati rendimenti di dati sempre lo stesso risultato, ma si è dimostrato di essere praticamente irreversibile, è possibile presentare in modo sicuro la chiave hash sul sito senza compromettere l'indirizzo di posta elettronica dell'utente. Inoltre, si può supporre con sicurezza che non esistono due hash di diversi messaggi di posta elettronica saranno gli stessi (che può essere, ma la probabilità che ciò accada è molto, molto piccolo). Per ulteriori informazioni sulle funzioni di hashing, consultare Wikipedia .

Answer 3

Vuoi dire cookie sessione ?

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

---

Quello che ha detto DzinX. L'unico modo per creare una chiave opaca che può essere autenticato senza andata e ritorno database utilizza la crittografia o un hash crittografico.

Dare all'utente un numero casuale e hash o cifrare con una chiave privata. È ancora esegue il (piccolo) rischio di collisioni, ma si può evitare questo toccando il database sulla creazione chiave, cambiando il numero casuale in caso di collisione. Assicurarsi che il numero casuale è crittografico, e aggiungere un lungo numero a caso sul lato server per prevenire attacchi di testo in chiaro scelto.

Vi ritroverete con un token come la chiave di Google Docs, in pratica una firma attestante l'utente è autenticato, che può essere verificata senza toccare il database.

Tuttavia, data la determinazione del prezzo dei GAE e la velocità di bigtable, siete probabilmente meglio utilizzare un ID di sessione, se davvero non è possibile utilizzare l'autenticazione proprio di Google.