You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by "yhs@mimic.onesourcecorp.com" <yh...@mimic.onesourcecorp.com> on 2000/09/22 20:59:08 UTC
Re: Session cookies, jvmRoute, and the root context
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 jchiu@spun.com 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-
yhs@mimic.onesourcecorp.com
Re: Session cookies, jvmRoute, and the root context
Posted by Paul Frieden <pf...@dchain.com>.
I've started looking into the cookie behavior, and I think I may have
found one problem, but I'm not sure if the fix fixes everything yet. In
the example below, it never states that it is using version 1 cookies,
so I will assume that it is using the default version 0 cookies. I
threw together a few JSP pages that work with cookies. I not only
couldn't change the values properly, I couldn't reliably delete the
cookies at all.
I went into the RFC that defines cookies and did some research there.
The RFC is available at http://www.w3.org/Protocols/rfc2109/rfc2109.
That current code sets the Expires header to be the current time on the
server plus the MaxAge. In the case of a MaxAge of 0, that makes the
Expires time be the current time on the server. The RFC refers to
setting a date long in the past to forcefully expire a cookie. I made
some changes to the code in org.apache.tomcat.utils.CookieTools, and
that seems to at least let me reliably delete cookies. The code
currently uses MaxAge >= 0. That treats MaxAge of 0 exactly the same as
a non-0 MaxAge and bases it off of the current time. I've added a
condition to detect MaxAge == 0 and version == 0 that sets the time way
into the past.
On an interesting note, Netscape on Linux doesn't like a cookie
expiration time of "Thu, 01-Jan-1970 00:00:00 GMT". It will not delete
the cookies properly. If I move the time a few hours later though, it
works great.
Why doesn't the current time force the browser to delete the cookie?
I'm guessing that the way the time is used it disregards the locale and
the difference between the server's time and the browsers time. Why
does it not show this behavior with no load balancing? I have no idea
yet. The patch might not be perfect, but I didn't want to mess up the
version 1 cookie handling because that seems to work.
Paul Frieden
"yhs@mimic.onesourcecorp.com" wrote:
>
> Hi paul,
>
> I've quoted josephs msg below as well as yours. To be specific on whats
> broken and needs to be fixed :
> Here's the first part of it :
> ---------------
> http://znutar.cortexity.com/BugRatViewer/ShowReport/27
> Report Description:
> I have two servers with identical servlets on both doing load
> balancing (1 JVM per server). For this example consider A1 to be servlet A
> running on server 1 and so on, B2 to be servlet B on server 2 etc.
> A1 -> set cookie to (say) abc=20
> B2 -> reads from the cookie. gets abc=20. correct.
> C2 -> deletes the cookie (setMaxAge to 0)
> C2 -> sets a new cookie abc=30
> C2 -> reads from the cookie. gets abc=30. correct.
> B1 -> reads from the cookie. gets abc=20 <---------------- bug.
> B2 -> reads form the cookie. gets abc=30. correct.
> I'm using mod_jserv.so to do the load balancing. using
> netscape 4.73 to access the servlets and tomcat 3.2b2 with blackdown
> JDK 1.2.2FCS on redhat linux 6.2 kernel 2.2.16-3. I cant offer any insight
> into whats causing it...AFAIK this
> behaviour was not present in 3.1 and changing the JDK doesnt help. it
> only occurs with load balancing and not with the regular non load balanced
> operation. It doesnt affect me any
> more since i've worked around it and dont care either way....but it
> shouldnt really be present anyway
> ---------------
>
> The second part is the jvmRoute thingy (josephs patch) which works for
> root only but breaks multiple servlet contexts. This needs to be fixed and
> ensure that it works in BOTH non loadbalanced as well as loadbalanced
> environments (i recommend testing with 250 concurrent users with at least
> 50 concurrent JVMS on two machines to be sure).
>
> The third part is that cookies dont work for lynx. period. either lynx or
> tomcat or the jdk needs to be patched. it should be a clean patch
> tho...cant afford to break netscape/IE/opera/etc and fix lynx.
>
> Thats it....as i said earlier its unlikely that a huge patch which fixes
> all of these things without breaking anything else will be included in 3.2
> or even 3.3....i dont really care either way, but it would be nice to have
> it fixed.
>
> -Ys-
> yhs@mimic.onesourcecorp.com
>
> On Mon, 25 Sep 2000, Joseph Chiu wrote:
>
> > Hi,
> >
> > Just to weigh in (as I'm being mentioned)... The "patch" that I originally
> > suggested was a kludge for our specific circumstance -- WE DON'T WANT to
> > have multiple servlet contexts in our site. Instead, we wanted one global
> > context shared among any/all servlets. Yes, it might seem crazy, but we
> > really have a method to our madness. Since we are essentially writing a
> > monolithic application (we use servlets to partition the work, not the
> > problem domain), the cookie-path-to-root is what we wanted.
> >
> > My trivial patch to make "RootOnlySessionInterceptor" addressed that
> > specific need. No more, no less. Yes, it breaks multiple servlet
> > contexts -- but I intended clearly to separate our special needs (RootOnly)
> > and not break the normal behavior (in the unmodified SessionInterceptor).
> >
> > Of course, we could just point to amazon.com and say that short paths are
> > old news (the home page is nested 4-directory deep)... But that's not in
> > our plans right now. :-p
> >
> > Thanks YHS and Costin, and to everyone that pitches in to the effort...
> >
> > Joseph
> >
> > ----
> > Joseph Chiu, Sr. Systems Architect - Spun.com, an idealab! company.
> > (626) 229-3148 (work) / (626) 643-2448 (cell)
> > Spun.com - Your Online Entertainment Exchange.
> >
> > -----Original Message-----
> > From: Paul Frieden (pfreiden@dchains.com)
> > Sent: Friday, September 22, 2000 4:16 PM
> > To: tomcat-dev@jakarta.apache.org
> > Subject: Re: Session cookies, jvmRoute, and the root context
> >
> >
> > 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
> >
> >
> > "yhs@mimic.onesourcecorp.com" 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 jchiu@spun.com 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-
> > > yhs@mimic.onesourcecorp.com
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
RE: Session cookies, jvmRoute, and the root context
Posted by "yhs@mimic.onesourcecorp.com" <yh...@mimic.onesourcecorp.com>.
Hi paul,
I've quoted josephs msg below as well as yours. To be specific on whats
broken and needs to be fixed :
Here's the first part of it :
---------------
http://znutar.cortexity.com/BugRatViewer/ShowReport/27
Report Description:
I have two servers with identical servlets on both doing load
balancing (1 JVM per server). For this example consider A1 to be servlet A
running on server 1 and so on, B2 to be servlet B on server 2 etc.
A1 -> set cookie to (say) abc=20
B2 -> reads from the cookie. gets abc=20. correct.
C2 -> deletes the cookie (setMaxAge to 0)
C2 -> sets a new cookie abc=30
C2 -> reads from the cookie. gets abc=30. correct.
B1 -> reads from the cookie. gets abc=20 <---------------- bug.
B2 -> reads form the cookie. gets abc=30. correct.
I'm using mod_jserv.so to do the load balancing. using
netscape 4.73 to access the servlets and tomcat 3.2b2 with blackdown
JDK 1.2.2FCS on redhat linux 6.2 kernel 2.2.16-3. I cant offer any insight
into whats causing it...AFAIK this
behaviour was not present in 3.1 and changing the JDK doesnt help. it
only occurs with load balancing and not with the regular non load balanced
operation. It doesnt affect me any
more since i've worked around it and dont care either way....but it
shouldnt really be present anyway
---------------
The second part is the jvmRoute thingy (josephs patch) which works for
root only but breaks multiple servlet contexts. This needs to be fixed and
ensure that it works in BOTH non loadbalanced as well as loadbalanced
environments (i recommend testing with 250 concurrent users with at least
50 concurrent JVMS on two machines to be sure).
The third part is that cookies dont work for lynx. period. either lynx or
tomcat or the jdk needs to be patched. it should be a clean patch
tho...cant afford to break netscape/IE/opera/etc and fix lynx.
Thats it....as i said earlier its unlikely that a huge patch which fixes
all of these things without breaking anything else will be included in 3.2
or even 3.3....i dont really care either way, but it would be nice to have
it fixed.
-Ys-
yhs@mimic.onesourcecorp.com
On Mon, 25 Sep 2000, Joseph Chiu wrote:
> Hi,
>
> Just to weigh in (as I'm being mentioned)... The "patch" that I originally
> suggested was a kludge for our specific circumstance -- WE DON'T WANT to
> have multiple servlet contexts in our site. Instead, we wanted one global
> context shared among any/all servlets. Yes, it might seem crazy, but we
> really have a method to our madness. Since we are essentially writing a
> monolithic application (we use servlets to partition the work, not the
> problem domain), the cookie-path-to-root is what we wanted.
>
> My trivial patch to make "RootOnlySessionInterceptor" addressed that
> specific need. No more, no less. Yes, it breaks multiple servlet
> contexts -- but I intended clearly to separate our special needs (RootOnly)
> and not break the normal behavior (in the unmodified SessionInterceptor).
>
> Of course, we could just point to amazon.com and say that short paths are
> old news (the home page is nested 4-directory deep)... But that's not in
> our plans right now. :-p
>
> Thanks YHS and Costin, and to everyone that pitches in to the effort...
>
> Joseph
>
> ----
> Joseph Chiu, Sr. Systems Architect - Spun.com, an idealab! company.
> (626) 229-3148 (work) / (626) 643-2448 (cell)
> Spun.com - Your Online Entertainment Exchange.
>
> -----Original Message-----
> From: Paul Frieden (pfreiden@dchains.com)
> Sent: Friday, September 22, 2000 4:16 PM
> To: tomcat-dev@jakarta.apache.org
> Subject: Re: Session cookies, jvmRoute, and the root context
>
>
> 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
>
>
> "yhs@mimic.onesourcecorp.com" 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 jchiu@spun.com 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-
> > yhs@mimic.onesourcecorp.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
RE: Session cookies, jvmRoute, and the root context
Posted by Joseph Chiu <jc...@spun.com>.
Hi,
Just to weigh in (as I'm being mentioned)... The "patch" that I originally
suggested was a kludge for our specific circumstance -- WE DON'T WANT to
have multiple servlet contexts in our site. Instead, we wanted one global
context shared among any/all servlets. Yes, it might seem crazy, but we
really have a method to our madness. Since we are essentially writing a
monolithic application (we use servlets to partition the work, not the
problem domain), the cookie-path-to-root is what we wanted.
My trivial patch to make "RootOnlySessionInterceptor" addressed that
specific need. No more, no less. Yes, it breaks multiple servlet
contexts -- but I intended clearly to separate our special needs (RootOnly)
and not break the normal behavior (in the unmodified SessionInterceptor).
Of course, we could just point to amazon.com and say that short paths are
old news (the home page is nested 4-directory deep)... But that's not in
our plans right now. :-p
Thanks YHS and Costin, and to everyone that pitches in to the effort...
Joseph
----
Joseph Chiu, Sr. Systems Architect - Spun.com, an idealab! company.
(626) 229-3148 (work) / (626) 643-2448 (cell)
Spun.com - Your Online Entertainment Exchange.
-----Original Message-----
From: Paul Frieden (pfreiden@dchains.com)
Sent: Friday, September 22, 2000 4:16 PM
To: tomcat-dev@jakarta.apache.org
Subject: Re: Session cookies, jvmRoute, and the root context
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
"yhs@mimic.onesourcecorp.com" 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 jchiu@spun.com 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-
> yhs@mimic.onesourcecorp.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Session cookies, jvmRoute, and the root context
Posted by Paul Frieden <pf...@dchain.com>.
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
"yhs@mimic.onesourcecorp.com" 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 jchiu@spun.com 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-
> yhs@mimic.onesourcecorp.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org