tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Frieden <>
Subject Re: Session cookies, jvmRoute, and the root context
Date Fri, 22 Sep 2000 23:16:10 GMT
If you could provide me with specifics on what it broke, that would  be
very helpful.  Dismissing it as an old bug is less than useful.  I tried
to search the bug system, but it doesn't ever respond.  I am willing to
spend the time to fix the issues involved if I can find an acceptable
solution.  I think the jvmRoute issue is mixed in with other more
general session handling issues, and not entirely related, but I may be
wrong in that regard.

I reviewed the patch I referenced, and found one difference.  That patch
always set the cookie path to /, where my patch hadn't done that.  All
my patch did was make sure that the jvmRoute was added to whatever
session had been selected already.

I'd like to try to resolve the real issues involved if possible.  It
looks like the current session code may return an incorrect session ID
if multiple session cookies are sent.  This is because while the server
sets the path for a cookie, the browser doesn't return the path the
cookie was set with.  If a client accessed the root context, as well as
another context for a particular server name, both session cookies will
be returned to the non-root context.  The current code simply selects
the first cookie that has the right name and assumes that it is the
correct one.  If that ID is invalid, it is assumed that there are no
valid ID's.

One possible solution would be to put the context name or path that the
session ID came from into the session id value.  That would make it
possible to correctly identify the particular cookie that belongs to
that session.  This would require some additional overhead of looking
through the entire list of cookies the browser returns, as well as
examining the values of those with the session cookie name.  It could be
configured by selecting which interceptor to use.

Another possible solution would be to have StandardSessionInterceptor
loop across all cookies with the proper name, and try each of them to
try to find a valid one for the context.  If the browser correctly
processes the cookie paths, there should be a maximum of 2 session
cookies returned, and most of the time the first one would be valid. 
That would probably have less overhead than the above solution and
wouldn't require a change to the format of the session cookie value.

This could also resolve a potential minor security bug.  If a site has
both a root and non-root context, the root context's cookies are also
returned, including the raw session cookies.  A hostile servlet in the
non-root context could then extract the session ID of the root context
from the cookie and send it to the author who could then gain access to
the root context.  I could write an interceptor that would remove
session cookies that are invalid to prevent them from leaking into
possibly hostile servlets.  That would make it configurable and remove
the overhead for those environments that do not need this.

Something that I think I've seen talked about on the list is to make the
actual session ID global to the server, but the contents local to the
context.  This side-steps the issue by only setting one session ID which
is used everywhere and you don't have to worry about which context it is
associated with to get the right one. This however does not address the
potential security problem mentioned above because the same ID is valid
in both contexts.

If this is an acceptable solution to the problem, I could try to
implement it.  If not, I would be open to suggestions and could do what
I can to fix the problem.

Paul Frieden

"" wrote:
> On Sat, 23 Sep 2000, Paul Frieden wrote:
> > Hello,
> >
> >       I have been testing Tomcat 3.2b4 and mod_jk.  I like to keep the URLs
> <SNIP>
> > just this was posted by on August 22 under the subject of
> > "Root-context sticky session workaround" with no reply.
> >
> >       I would appreciate any comment as to why this is the way it is.  Am I
> > missing something that justifies this behavior in some scenarios?  I
> *sigh* old bug. the reason it was never applied was because the patch
> broke stuff (and thats according to the original patch writer too). too
> many changes to tomcat to make this work properly..someone needs to sit
> down and work on it. i doubt its going in 3.2 or even 3.3....
> -Ys-
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

View raw message