[Web-SIG] Standardised configuration.

Phillip J. Eby pje at telecommunity.com
Mon Sep 6 16:21:27 CEST 2004


At 03:48 PM 9/6/04 +0200, Paul Boddie wrote:
>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).


Just to throw another thought in here, keep in mind that one could write a 
"cookie consolidator" WSGI component that would send its own 
session-management cookie to the client after removing application-sent 
cookies from the responses and saving them somewhere locally.  When a 
request comes in, the "cookie consolidator" would read its own cookie from 
HTTP_COOKIE, and then add the stored cookie data before passing it on to 
the application.  So, from the app's point of view, it's as if all the 
cookies are going to the client, but in reality there's only one, with the 
rest of the data stored server-side.

One could presumably also extend this cookie consolidator to manage other 
kinds of session keys as well, such as ones embedded in the URL.  Or, for 
that matter, you could write one that embeds its session key in the URL 
instead of in a cookie, but still makes it look to the application as if 
cookies are being used.



More information about the Web-SIG mailing list