[Web-SIG] Standardised configuration.

[Paul Boddie]

Alan Kennedy wrote:
> 
> I think that session handling is an excellent example against which to

> have this discussion. Note however that I am *not* advocating 
> standardising session management under WSGI.

There will be plenty of other places to standardise it, I'm sure. ;-)

> J2EE session handling is generally a huge PITA, primarily because the 
> base unit of session management is the servlet context, i.e. every 
> servlet context gets its own "session space". For example
> 
> '/forms' may map to one session space, while
> '/news' may map to a different session space.
> 
> Any given user may have multiple sessions on a server, depending on
the 
> number of servlets they have interacted with. It is generally not 
> possible, except using container specific methods, to have a single 
> "uber-session" which concentrates all user session data into a single 
> object. This "hierarchy problem" makes it difficult, and extremely 
> container-specific, to manage a single set of users across a set of
J2EE 
> servlets.

Session sharing sounds like a great idea, and I've seen some pretty
unfortunate workarounds to achieve such things, but then overreliance on
such mechanisms can be very restrictive if you change the "topology" of
your
system architecture (ie. relocate one application to another server).

> Most J2EE containers support both cookies and URL rewriting for
session 
> management, i.e. if the user-agent has cookies disabled, then all urls

> are rewritten to contain sessions IDs. Which means that the url 
> rewriting algorithm has to be aware of multiple servlet contexts, and 
> rewrite local urls to contain the session ID which is specific to the 
> target context/servlet.

This is a pretty nasty problem that WSGI and other technologies could do
relatively cleanly for once.

> Some J2EE containers support a "Single Sign On" facility, where the 
> container manages the multiple session objects on the applications 
> behalf, and makes it easy for the user (but not the programer) by only

> making them sign on to a server once. Tomcat does this using an extra 
> cookie, the SSO cookie, which is transmitted to user-agents *as well
as* 
> the per-servlet cookie, i.e. the user-agent receives two cookies from 
> the container. Worse, the Tomcat Single-Sign-On facility does not 
> support URL rewriting: the user-agent *must* have cookies enabled in 
> order for single sign on to work. Which sucks.

I guess you haven't seen other SSO solutions, then, or are too polite to
mention them. ;-)

> I think that if WSGI applications were to rely on the local 
> platform/container session management facilities, it is extremely 
> unlikely that they would be portable. It's difficult enough to get 
> coherent cross-servlet session-handling working on J2EE when writing
in 
> java, as these pages show
> 
>
http://jakarta.apache.org/tomcat/tomcat-5.0-doc/config/host.html#Single%
20Sign%20On
>
http://jakarta.apache.org/tomcat/tomcat-5.0-doc/config/valve.html#Single
%20Sign%20On%20Valve
> http://www.fwd.at/tomcat/sharing-session-data-howto.html
> 
> Imagine the complications if the application code were originally 
> written to work with say, WebWare under cpython?

Sharing sessions between completely different framework implementations
(eg.
Webware and mod_python) within some kind of WSGI infrastructure is going
to
be an extremely difficult thing to achieve, mostly because the session
store
implementations are probably not interoperable - I haven't checked, but
the
chances of interoperability are fairly low, I would think. My opinion is
that as soon as you're sharing session information, you're moving
towards
some kind of shared database situation, anyway.

> To me, session handling is one of those things that is done in so many

> different ways by so many different platforms/containers that it is 
> impractical to achieve application portability once a particular 
> methodology has been chosen.

You'll have to clarify that. I've been working on WebStack functionality
which at least allows applications to treat sessions in the same way,
and it
shouldn't be surprising that this is possible given the narrow range of
operations that most session implementations expose. Of course, were it
possible for an application running on Webware to suddenly, between HTTP
requests, find itself "migrated" to Twisted, it would be a bit much to
expect that application to find its sessions intact after the move.

> So, IMHO, session handling is one of those "should be simple" areas of

> web programming that gets horrifically complicated when trying to move

> applications between platforms/containers: in fact I'd go so far as to

> say the multiple session handling techniques is one of the primary 
> reasons why the python web world is currently so fragmented: every 
> framework author thinks they know best: although some do it much
better 
> than others. I like webwares method of using URL path parameters, with
a 
> auto-refresh if a request is received that doesn't contain a session
ID. 
> But IIRC, this method is quite Apache specific, and requires 
> modification of the Apache httpd.conf to get working. I could be wrong

> though.

Are you advocating a common session manager? I can see some major
benefits
with something like that.

Paul