I've been using wsgi middleware quite a bit lately, partly because my framework uses it extensively, and it occurred to me that maybe the whole session middleware stuff is an overly complex solution that might not ever work ideally.
This isn't to say that the problem doesn't exist, rather that perhaps looking to put the session itself in middleware isn't the greatest solution at this juncture. As the debate regarding how to make session middleware showed, many frameworks have different ideas about how the session works, ideas they aren't ready to give up. However, almost all (if not all) session implementations do share two common themes: - A unique ID is used to tag the session - This unique ID is put into a cookie, typically signed/hashed some way to prevent hijacking/spoofing The key reasons for session middleware: - Ability to share data between multiple WSGI apps regardless of framework - Reduce duplication of effort (though all the frameworks already have sessions....) First, a huge problem I see despite all the other debate on session middleware. If you have multiple instances of the same webapp, you'd need to tell each webapp to prefix itself in some unique way to avoid session key conflicts. Second, to share data, the webapps will need to know in advance no matter what, that there is extra "stuff" they might want to look for in the session. So here's my solution: - No session middleware - Cookie middleware (paste.auth.cookie already provides a secure cookie for you) - Modify the frameworks in question to have the ability to get their session ID from environ['session.id'], rather than doing cookie business themselves Essentially, rather than trying to have frameworks ditch their session in favor of something else, the framework keeps its session, and gets the ID of it from a more minimal cookie middleware layer. If webapps want to share small tidbits of information, they add it to the secure cookie. The most common, besides for a session ID (so the other webapp instances can have sessions stay active across webapps), would be a login token. This way if the user crosses into a different webapp that the user hasn't logged into yet, the other webapp would see by the login token that the user has successfully logged in elsewhere, and it would then setup its own session with the same ID, and load the user record for that login token. Maybe you have a back-end xml-rpc server that gives you user profile data so you can retain profile data across webapps that are logging in someone who never setup a user record with them... Keeping the ID and login token in the cookie makes it easy to scale across multiple servers, etc. As far as I can tell, all thats required to get this going is the desire to do it, and minor feature enhancements to some frameworks (no idea which ones). The framework just needs the ability to not use its own cookies for sessions, and load a session given an ID. Anyways, any thoughts on this? The requirements are low and in reach right now with a minimal of effort, so rather than just talk, this will be easy to actually do and see how it works... Cheers, Ben _______________________________________________ Web-SIG mailing list [email protected] Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
