So this discussion has been going on for quite some time, and each time I saw this email come by I figured there has to be a better way than to continue going on whether there should be an session_id on the session or not.
I personally don’t think there should be, and it should be implementation defined, so to that end I have actually ended up writing pyramid_pluggable_session. It’s really simple, it even takes the same parameters as the default SignedCookieSessionFactory(), it couldn’t be simpler … ;-) So here you can find the code: https://github.com/usingnamespace/pyramid_pluggable_session Now, this is 0.0.0dev, that is no checking what so ever, no tests, nothing, and it only comes with a single pluggable interface, and it uses local memory without threading support so it’s dangerous, but sometimes I like to live on the edge ;-) I hear you say, well how do I use it… perfect, stick this in your .ini: pluggable_session.secret = ThisShouldBeSecret pluggable_session.plug = pyramid_pluggable_session.memory.MemorySessionPlug And add: pyramid_pluggable_session to your pyramid_includes or do config.include(‘pyramid_pluggable_session’). Plugging is simple: https://github.com/usingnamespace/pyramid_pluggable_session/blob/master/pyramid_pluggable_session/memory.py Now, the backend in my case simply needs to store the opaque object, the backend shouldn’t care what the data being stored is at all, which even in the case of using a database is perfect, no exploding amount of tables required, cause normalisation doesn’t come into play here. Now each loads() gets access to the session object (the only thing initialised at that time is the session_id though …) and the request (that is where you can stash your connections to redis/database and get access to the registry). Each dumps() gets access to the session object, this time all the required ISession variables are available, such as .created, so you can store that in your DB for expiration purposes, along with the session_id of course, and then the request object, and the session_data. In my implementation the session_data is serialized using Pickle, it is then Signed. This means that even data coming from the backend is verified that it hasn’t been tampered with (or more likely, no data corruption has happened). The only thing sent to the client is a cookie containing the session id. Now the session id is 20 bytes of random that has been hexlified. The cookie data is serialised/signed using the SignedCookieHelper in WebOb. So if someone wanted to tamper with the cookie (to change the session ID for example) they would also need to know your secret… Now go forth and enjoy. I’ll accept pull requests for file based storage, redis/mongo/db based storage, and other stuff like that. Or even better, create pyramid_sessplug_<name>, so that people that want to use certain ones can use them. Bert JW Regeer
smime.p7s
Description: S/MIME cryptographic signature
