views:

47

answers:

2

Hi there,

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

+1  A: 

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
@Moraes: Thanks for the reply. I certainly think secure cookies are the canonical way to go about doing this.
Brian M. Hunt
+1  A: 

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