Re: [Webware-discuss] Anybody made a memcached SessionStore?

[Ben Parker]

Geoffrey Talvola wrote: If others have input/experience with clustered appservers or alternative session store algorithms, please speak out! Peace - Ben There's the option of not using a server-side session store at all. If your session data is guaranteed to be small, and if you can rely on cookies being enabled, then a solution using encrypted cookies is kind of appealing because it avoids the issue of server-side session stores entirely. I'm thinking of a solution like the one used in pyWeb: http://www.freenet.org.nz/python/pyweb/docs/index.html I have no experience with this, but the idea sounds interesting to me. - Geoff Fortunately or unfortunately, cookie support must not be required for this particular application. We do use cryptographically signed cookies to remember the user and prepopulate their email address into the login form, but that's about it. The pyWeb solution looks interesting for small (or compressible) non-critical session data though. I just skimmed the session description and can recap for the list: As opposed to storing the session in a server side store like Webware sessions, pyWeb sessions are "pickled, zlib-compressed, converted to base 64, cryptographically signed then written to one or more cookies". Since cookies have a 2K limit (or should), pyWeb handles breaking up the pickled-compressed-base64'd-signed session data into multiple cookies, and reassembling them again on the next request. More on pickling sessions and then sending them beyond your control, from the pyWeb session notes: "2. Yes (I hear the Python boffins scream!), Python pickles are horribly insecure. It's said that a malformed pickle can cause the python interpreter to execute any arbitrary code. So for your protection against 5cr1p7 X1dd1e5, pyWeb creates a signed hash (hmac/sha1) and adds it to the header cookie. Therefore you can trust that any data which comes back is exactly what you sent to the client (as long as you haven't maxed out the size of the incoming Cookie header, that is). If some 14m3 h4X0r tries something on, this datastore will be empty upon page creation, with page.session.error set to an appropriate error value." This approach is effectively a SessionFileStore which uses the client as the store. The clobbering problem is still there: the user can hit Page A with Cookies of State 1, and then while Page A is loading the user hits Page B and their browser sends the session data still in State 1. Then Page A modifies the session data and sends to the client in State 2, then Page B completes and sends the session data to the client possibly still in State 1. Page B's version of the session data will clobber the version set by Page A. - Ben ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ Webware-discuss mailing list Webware-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/webware-discuss