I think it's a case of it's been that way for so long I haven't realized I need to change it. The put on every write to update the last activity, I mean. I'll look into modifying it so that it only writes when the session token changes.
As for google though, every time I load up my igoogle page, I have cookie called SID for the www.google.com that changes each page view. This is really as it should be for real security, as even the 15 second window I have configured by default it more that large enough for someone to write a script very quickly to sniff and grab the cookie to be used to hijack the session. Modifying the last_activity to update less frequently is a good idea, I will try to get that in soon. On Jan 22, 2:08 pm, jeremy <jeremy.a...@gmail.com> wrote: > Bowman - I think my issue with gaeutilities may largely be that the > default settings seem excessive. Looking at the cookies google.com > hands its visitors, their SID cookie lasts a good decade and seems to > rotate every few hours, not seconds. So at the moment i'm thinking > I'll see if changing the default satisfies me. > > Also, at the moment there's a datastore put() on every session-using > request to (at a minimum) update the last activity time stamp. But if > my SESSION_TOKEN_TTL is something like 1 hour, then actually i only > need to update the last activity time stamp if the last timestamp was > more than an hour ago. That would significantly reduce the amount of > datastore writes, no? > > re: "I'm just trying to figure out the value in the signed cookie > approach, because if I can figure out a way for it to make sense I > would consider moving gaeutilities to that approach. ": > > Do you mean storing all session data in the clients cookie and using a > signature to authenticate it? That approach makes me nervous, although > I can imagine it's actually quite effective. You just store the > session data in plain text but then also include a signature = SHA1 > (session_data + secret_key_only_the_server_knows). That way the server > can confirm it was the one who committed the values (and not the > client messing with their own cookies). > > On Jan 21, 8:33 pm, "bowman.jos...@gmail.com" > > <bowman.jos...@gmail.com> wrote: > > Does beaker store all session information as cookies? > > > I'm just trying to figure out the value in the signed cookie approach, > > because if I can figure out a way for it to make sense I would > > consider moving gaeutilities to that approach. > > > gaeutilities stores only a temporary session token in the browser > > cookie store, all information is stored server side for security. > > Since I only have the one cookie, which is basically an id to find the > > session server side with, I don't see a way for this approach to keep > > a session from being hijacked. As in the end the 'hash-value' string > > could be hijacked and reused by another browser. > > > The performance issue with gaeutililites, and why Jeremy is looking > > for options, is the approach I've taken to securing the session id > > requires frequent put() operations. I've seen some other blogs who've > > mentioned this is a performance bottleneck for gae, but I haven't been > > able to come up with another approach that will not sacrifice > > reliability or performance. Basically I rotate the session id in the > > cookie every 5 seconds (this length is configurable). I store the > > current plus previous 2 tokens in a ListProperty in order to manage > > sites using AJAX type functionality. A session token is generally good > > for 15 seconds with this approach. Longer if there are not interim > > requests generating new tokens, as a new token is only generated when > > the 5 second TTL is hit. So you come back 2 minutes later, and the > > session token is still valid for that request, just regenerated on the > > request. As you can imagine, this is a lot of put operations for each > > session. > > > I deemed just using memcache to not be a viable alternative because > > it's documented that it's a volatile storage, it can be cleared at any > > time. I do use memcache for speeding up reads to the session data, > > limiting read access to the datastore. > > > I'm definitely open to suggestions for a method to do this without all > > the puts. The key being the reliability and security are more > > important than performance. In the end it's cheaper to pay for the CPU > > usage than the risks by allowing users to have their sessions easily > > hijacked, depending on the application, or having sessions randomly > > lost due to the storage medium not being permanent enough. > > > On Jan 21, 6:27 pm, jeremy <jeremy.a...@gmail.com> wrote: > > > > thanks for the suggestions. > > > > does beaker really work out of the box with gae? > > > > On Jan 21, 1:06 am, Ian Bicking <i...@colorstudy.com> wrote: > > > > > On Tue, Jan 20, 2009 at 10:40 PM, jeremy <jeremy.a...@gmail.com> wrote: > > > > > can anyone recommend / mention a session manager other than the one in > > > > > gaeutilities? > > > > > Beaker works with GAE:http://beaker.groovie.org/ > > > > > -- > > > > Ian Bicking | http://blog.ianbicking.org --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~----------~----~----~----~------~----~------~--~---
