joerussbowman / gaeutilities

gaeutilities - A collection of utilities to help with application development on Google Appengine
http://gaeutilities.appspot.com
BSD 3-Clause "New" or "Revised" License
78 stars 4 forks source link

Model, and model access changes for performance #16

Closed joerussbowman closed 14 years ago

joerussbowman commented 14 years ago

Based off of this thread - http://groups.google.com/group/google-appengine-python/browse_thread/thread/9227627627a6671e?hl=en

It could be possible that the querying for the sid, when there are a large amount of session objects, could cause performance degradation. It's my understanding of how bigtable works that this should not be the case, but it is a well known fact that getting a an object by key is quicker than any query.

So, while these changes would be pretty extensive, I propose that the following changes be made.

This should improve over all performance.

As a note, I'm still in the middle of another project and do not have a lot of time to work on this. I'll see if I can get some time to knock it out, but if anyone wants to volunteer, I'm open to pull requests.

Arachnid commented 14 years ago

Are you randomly generating key names? If not, switching to using the model key introduces a huge security issue: Anyone can guess other users' session IDs very easily.

joerussbowman commented 14 years ago

The key for each session is two parts. persistent-identifier_token.

I was using a time based hash to create the persistent-identifier when the session is created, and would then create the first token. The tokens rotate on a scheduled basis, generally every 5 seconds, with the most recent 3 tokens being usable. Basically, gives a 15 second window for valid keys, depending on the amount of requests the client is making to the server of course.

What I've just committed is a change that moves the time based as for the persistent identifier to be the model.key() of the session entity in the datastore. This cuts down on the overhead of creating unique identifiers, which the datastore does anyway. If there is some predictability in these identifier, the token is still the primary rotating security key, which is randomly generated.

joerussbowman commented 14 years ago

This is done.