[Web-SIG] Session Middleware....apparently on hold, why not solve an easier problem first?
ben at groovie.org
Sat Jan 7 06:39:02 CET 2006
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
- 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
- Reduce duplication of effort (though all the frameworks already
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
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...
More information about the Web-SIG