1

I'd like to have a mapping of users to accounts, and then have users directed to a namespace corresponding to their account.

Having looked at the appengine_config.py from the suggested example, there appear to be a few suggested ways to determine what the namespace ought to be, i.e.

  1. Server name
  2. Google Apps Domain
  3. Cookie

I would like to have namespaces selected based on a lookup in the datastore. i.e. 

namespace = user.account.name

For some user object that is linked to an account, which account has a name field. There area few ways I've posited to accomplish this:

  1. datastore lookup on each request
  2. memcache lookup on each request (fallback to datastore when memcache expires)
  3. secure cookie data

The datastore lookup would be two slow. Is there any such reservation with a memcache lookup? e.g. memcache.get('nslookup:%s' % user_id), given a user_id. (I trust the users object works as expected in appengine_config.py).

Alternatively, one could use a secure cookie to solve this. I'm not satisfied with the security of the "Secure" flag (i.e. forcing SSL). However, I'm not sure about how best to secure the data in the cookie. I suppose symmetric encryption with signing with PyCrypto using a secret key in GAE along is one way to get started on this path. Although this pattern has been vetted, I'd be grateful for any thoughts on this suggested solution in particular.

Secure cookies don't seem the best route from an idealogical standpoint; I already expect to have the user identity, all I need is a mapping from the user to their account - there is no logical basis for encrypting, sending, storing, receiving, and decrypting that mapping on every request. The memcache options seems best of the three, but I'd be grateful for thoughts and input. The only reason I can think of to use secure cookies would be performance, or alternatively if memcache access were unavailable in the appengine_config.py.

Thoughts and input and challenges to my assumptions are most welcome.

Thank you for reading.

Brian

Community
  • 1
  • 1
Brian M. Hunt
  • 81,008
  • 74
  • 230
  • 343
  • What do you use to look up the record in the datastore? And what namespace is _that_ record in? Also, are you positive each user only needs to access their own data? If users commonly read or write data accessible by other users, per-user namespaces may not be the best option. – Nick Johnson Aug 31 '10 at 16:06
  • @Nick Johnson: I've not yet decided what to use to look up the record in the datastore (presuming that's where it would be, which I assume it would); it would have to be in a 'master' namespace. The namespaces aren't per-user, but-per account (i.e. sets of users). Cross-account access would be handled by proxy requests. – Brian M. Hunt Sep 02 '10 at 18:38
  • My point was that if you have a way to construct a key to look up a record in the datastore, you can simply use that value as your namespace name, instead of doing the lookup. And by 'proxy requests', I hope you don't mean doing a request to yourself using urlfetch - you can simply change the default namespace inside the request, instead! – Nick Johnson Sep 03 '10 at 08:35

2 Answers2

1

I think that secure cookies are the way to go because they are fast enough. A basic implementation extracted from Tornado is here (you just need the SecureCookie class and can ignore the "session" stuff):

http://code.google.com/p/webapp-improved/source/browse/extras/sessions.py#104

moraes
  • 13,213
  • 7
  • 45
  • 59
1

Performance-wise, anything that avoids a need for memcache or datastore lookups on each request is going to be the best option. You're confusing two definitions of 'secure' cookie, though: the 'secure' flag in the cookie spec mandates that the cookie is only sent over SSL, while in the other sense, a 'secure' cookie is one that cannot be modified undetectably by the user - which is what is most important in this use case.

There's no need to encrypt the contents, though - you want to prevent modification, not disclosure - so if you can't use an existing library, you can simply append an HMAC of the cookie to the end of it, using a secret key that you embed in your application. Verifying the HMAC on each request will be much faster than using memcache.

Nick Johnson
  • 100,655
  • 16
  • 128
  • 198