[Web-SIG] Session Middleware....apparently on hold, why not solve an easier problem first?

[Ben Bangert]

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