[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