On Jul 26, 2009, at 3:33 AM, Matt N wrote: > A few questions about Beaker's sessions here. > > Firstly, I've been looking through the documentation but I haven't > been able to find a function that refreshes the session id whilst > keeping the contents of the session (for example, the equivalent of > PHP's session_regenerate_id function). There are functions that will > create a new session id, but also destroy the session data, which > isn't what I'm after. Is there some way to do this that I have > overlooked?
Ah, what's the purpose of retaining the session data but making a new session ID? No one has ever mentioned that need, so Beaker doesn't have that feature. > Secondly, take the following contents of a session cookie: > > b294dbff592d6a57085d5300a10f5a68f7a67c1c8702cfcbdb6ec82a478515de712b54ae > > This looks to be made up of two parts, a md5 hash > (8702cfcbdb6ec82a478515de712b54ae) which is the actual session id, but > I haven't been able to work out the role of the (sha1?) hash preceding > it, anyone care to enlighten me? The SHA is a signature of the md5 hash. This is to prevent tampering, ie, someone can't start generating various cookie id's looking for one that might be in use, because they won't be able to generate the appropriate SHA signature for it (since the value the md5 is SHA'd against is known only to the server). > And finally, at this point it looks like my application will only be > using sessions to store a user's ID for authentication/authorization > purposes (and possibly a bit of preference data). I remember seeing > someone recommending cookie-based sessions as apposed to file/ > database/ > memory backed sessions, this would be faster than the alternatives and > one less bit of backend work to worry about, though would you consider > this suited well for this purpose? Is the encryption used to protect > this data considered secure enough? (I plan to validation these > through user-agent, and possibly by partial IP addresses). If you're storing data that isn't valuable (ie, just some simple data about access permissions), I don't see any reason to use the encryption, since the cookies are all signed to prevent tampering people can't change them anyways. If you actually want to store some data that a user should *not* be able to see, then you'd want the encrypted cookie-based session. They use a 256-bit AES stream cipher, which I'd consider pretty dang secure. Cheers, Ben --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
