Gerando IDs de usuário exclusivos e opacos no Google App Engine

Question

Estou trabalhando em um aplicativo que permite que os usuários registrados criem ou enviem conteúdo e permite que os usuários anônimos visualizem que o conteúdo e navegam nas páginas dos usuários registrados para encontrar esse conteúdo - isso é muito semelhante a como um site como o Flickr, por exemplo, permite pessoas para navegar nas páginas de seus usuários.

Para fazer isso, preciso de uma maneira de identificar o usuário no HTTP anonymous Get Solicy. Um usuário deve ser capaz de digitar http://myapplication.com/browse/<userid>/<contentid> E chegue à página certo - deve ser único, mas não deve ser algo como o endereço de e -mail do usuário, por motivos de privacidade.

Através do Google App Engine, posso obter o endereço de e -mail associado ao usuário, mas, como eu disse, não quero usar isso. Posso fazer com que os usuários do meu aplicativo escolham um nome de usuário exclusivo quando se registrarem, mas gostaria de tornar isso opcional, se possível, para que o processo de registro seja o mais curto possível.

Outra opção é gerar alguns cookies aleatórios (um GUID?) Durante o processo de registro e usar isso, não vejo uma maneira óbvia de garantir a singularidade desse cookie sem uma viagem ao banco de dados.

Existe uma maneira, dado um objeto de usuário do mecanismo de aplicativo, de obter um identificador exclusivo para esse objeto que pode ser usado dessa maneira?

Estou procurando uma solução Python - esqueci que o GAE também suporta Java agora. Ainda assim, espero que as técnicas sejam semelhantes, independentemente do idioma.

Answer 1

Seu tempo é impecável: ontem, um novo lançamento do SDK foi lançado, com apoio para IDs de usuário únicos e permanentes. Eles atendem a todos os critérios que você especificou.

Answer 2

Eu acho que você deve distinguir entre dois tipos de usuários:

1) Usuários que fizeram login através de contas do Google ou que já se registraram no seu site com um endereço de e-mail que não é do Google

2) Usuários que abriram seu site pela primeira vez e não estão conectados de forma alguma

Para o segundo caso, não vejo outra maneira senão gerar uma string aleatória (por exemplo, via uuid.uuid4() ou a partir da chave de cookie da sessão deste usuário), como um usuário anônimo não possui nenhuma informação única consigo mesmo.

Para usuários que estão conectados, no entanto, você já tem um identificador exclusivo-o endereço de e-mail. Eu concordo com suas preocupações com a privacidade - você não deve usá -lo como identificador. Em vez disso, que tal gerar uma string que parece Random, mas de fato é gerado a partir do endereço de e-mail? As funções de hash são perfeitas para esse fim. Exemplo:

>>> import hashlib

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

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

Como hashlib.sha1 não é uma função aleatória, mas, para dadas as devoluções de dados sempre o mesmo resultado, mas é comprovado que é praticamente irreversível, você pode apresentar com segurança a chave de hash no site sem comprometer o endereço de e-mail do usuário. Além disso, você pode assumir com segurança que dois hashes de e-mails distintos serão os mesmos (eles podem ser, mas a probabilidade de isso acontecer é muito, muito pequena). Para obter mais informações sobre funções de hash, consulte A entrada da Wikipedia.

Answer 3

Você quer dizer Cookies de sessão?

Tentar http://code.google.com/p/gaeutities/

---

O que Dzinx disse. A única maneira de criar uma chave opaca que pode ser autenticada sem uma ida e volta ao banco de dados é usar criptografia ou hash criptográfico.

Dê ao usuário um número aleatório e o hash ou criptografa -o com uma chave privada. Você ainda executa o risco (minúsculo) de colisões, mas pode evitar isso tocando no banco de dados na criação de chaves, alterando o número aleatório em caso de colisão. Verifique se o número aleatório é criptográfico e adicione um longo número aleatório do lado do servidor para evitar ataques de texto simples escolhidos.

Você acabará com um token como a chave do Google Docs, basicamente uma assinatura provando que o usuário é autenticado, que pode ser verificado sem tocar no banco de dados.

No entanto, dado o preço do GAE e a velocidade do BIGTABLE, você provavelmente é melhor usar um ID da sessão se realmente não puder usar a autenticação do Google.