You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Jose María Zaragoza <de...@gmail.com> on 2013/03/01 20:46:05 UTC
Re: Multiple JSESSIONID
Thanks for your answers.
I wonder why browsers don't send only one JSESSIONID
If I request an URL as www.mydomain.com/app/myapplication/action.do
and it has got 2 cookies with the same name, one for www.mydomain.com/
and another for www.mydomain.com/app/myapplication/ , IMHO, that a
browser should send the most restrictive
Indeed, I don't know if there is some browser working like that.
Christopher,
if the browser sends a JSESSIONID to Tomcat and this JSESSIONID is not
tracked by the server , does any error happen ? or is it created a
new session with a new identifier ?
Thanks and regards
2013/2/28 Caldarale, Charles R <Ch...@unisys.com>:
>> From: Nick Williams [mailto:nicholas@nicholaswilliams.net]
>> Subject: Re: Multiple JSESSIONID
>
>> > That's interesting. I would recommend a servlet filter that captures
>> > addCookie and friends to see where that "extra" one is being added.
>
>> The two JSESSIONIDs immediately above are in the request, so they're added
>> by the browser, not the server
>
> Unless the browser is part of a hacking attack, the JSESSIONID cookies originally came from the server. The filter would have to be applied to both the ROOT and /app/myapplication contexts, so it might best be placed in conf/web.xml to cover all webapps.
>
> - Chuck
>
>
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Multiple JSESSIONID
Posted by Jose María Zaragoza <de...@gmail.com>.
2013/3/1 Nick Williams <ni...@nicholaswilliams.net>:
> APOLOGIES FOR TOP POSTING! (see below, were I correctly inline post this apology)
>
> On Mar 1, 2013, at 1:58 PM, Nick Williams wrote:
>
>> Browsers send all of the cookies because that's the compliant thing to do. RFC-2109 [1] says:
>>
>>> If multiple cookies satisfy the criteria above, they are ordered in
>>> the Cookie header such that those with more specific Path attributes
>>> precede those with less specific. Ordering with respect to other
>>> attributes (e.g., Domain) is unspecified.
>>
>>
>> Based on that, assuming Tomcat follows the rules Christopher says it does, you should be okay. The /app/myapplication cookie should always come first, and assuming it is valid Tomcat should always prefer it.
>>
>> Nick
>>
>> [1] http://www.ietf.org/rfc/rfc2109.txt
>
> My apologies for top posting! I don't normally do that. Slip of the keyboard...
Thanks Nick
My apologies for top posting, too. I forgot it
Regards
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Multiple JSESSIONID
Posted by Nick Williams <ni...@nicholaswilliams.net>.
APOLOGIES FOR TOP POSTING! (see below, were I correctly inline post this apology)
On Mar 1, 2013, at 1:58 PM, Nick Williams wrote:
> Browsers send all of the cookies because that's the compliant thing to do. RFC-2109 [1] says:
>
>> If multiple cookies satisfy the criteria above, they are ordered in
>> the Cookie header such that those with more specific Path attributes
>> precede those with less specific. Ordering with respect to other
>> attributes (e.g., Domain) is unspecified.
>
>
> Based on that, assuming Tomcat follows the rules Christopher says it does, you should be okay. The /app/myapplication cookie should always come first, and assuming it is valid Tomcat should always prefer it.
>
> Nick
>
> [1] http://www.ietf.org/rfc/rfc2109.txt
My apologies for top posting! I don't normally do that. Slip of the keyboard...
>
> On Mar 1, 2013, at 1:46 PM, Jose María Zaragoza wrote:
>
>> Thanks for your answers.
>>
>> I wonder why browsers don't send only one JSESSIONID
>> If I request an URL as www.mydomain.com/app/myapplication/action.do
>> and it has got 2 cookies with the same name, one for www.mydomain.com/
>> and another for www.mydomain.com/app/myapplication/ , IMHO, that a
>> browser should send the most restrictive
>>
>> Indeed, I don't know if there is some browser working like that.
>>
>>
>> Christopher,
>> if the browser sends a JSESSIONID to Tomcat and this JSESSIONID is not
>> tracked by the server , does any error happen ? or is it created a
>> new session with a new identifier ?
>>
>> Thanks and regards
>>
>>
>>
>> 2013/2/28 Caldarale, Charles R <Ch...@unisys.com>:
>>>> From: Nick Williams [mailto:nicholas@nicholaswilliams.net]
>>>> Subject: Re: Multiple JSESSIONID
>>>
>>>>> That's interesting. I would recommend a servlet filter that captures
>>>>> addCookie and friends to see where that "extra" one is being added.
>>>
>>>> The two JSESSIONIDs immediately above are in the request, so they're added
>>>> by the browser, not the server
>>>
>>> Unless the browser is part of a hacking attack, the JSESSIONID cookies originally came from the server. The filter would have to be applied to both the ROOT and /app/myapplication contexts, so it might best be placed in conf/web.xml to cover all webapps.
>>>
>>> - Chuck
>>>
>>>
>>> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
Re: Multiple JSESSIONID
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Jose,
On 3/2/13 2:25 PM, Jose María Zaragoza wrote:
>> The moral of the story is that nested URL spaces is a bad idea
>> where sessions are concerned. We easily fixed that problem by
>> moving the /-mounted webapp to a unique URL prefix (which wasn't
>> trivial, since we had inter-webapp links, etc.) but it solved all
>> of those weird problems.
>
> Thanks. But I've observed that any answer recommends to me to
> changing JSESSIONID name. And I don't know why because that is the
> reason of my problems : same cookie name for different contexts
Everything would have been okay if we didn't have that pesky context
that *uses* a JSESSIONID, but can't actually determine which
JSESSIONID represents a valid session.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEAREIAAYFAlEyoF8ACgkQ9CaO5/Lv0PAtLQCcDridClsWHSuFR5nz2Xe0fcog
GuAAni310NLRnYGadk6VrtlBUf43ZmWD
=FaGI
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Multiple JSESSIONID
Posted by Jose María Zaragoza <de...@gmail.com>.
> The moral of the story is that nested URL spaces is a bad idea where
> sessions are concerned. We easily fixed that problem by moving the
> /-mounted webapp to a unique URL prefix (which wasn't trivial, since
> we had inter-webapp links, etc.) but it solved all of those weird
> problems.
Thanks.
But I've observed that any answer recommends to me to changing JSESSIONID name.
And I don't know why because that is the reason of my problems : same
cookie name for different contexts
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Multiple JSESSIONID
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Nick,
On 3/1/13 2:58 PM, Nick Williams wrote:
> Browsers send all of the cookies because that's the compliant thing
> to do. RFC-2109 [1] says:
>
>> If multiple cookies satisfy the criteria above, they are ordered
>> in the Cookie header such that those with more specific Path
>> attributes precede those with less specific. Ordering with
>> respect to other attributes (e.g., Domain) is unspecified.
>
>
> Based on that, assuming Tomcat follows the rules Christopher says
> it does, you should be okay. The /app/myapplication cookie should
> always come first, and assuming it is valid Tomcat should always
> prefer it.
There is one caveat that you should be aware of: if Tomcat does not
recognize any of the session ids as valid,
HttpServletRequest.getRequestedSessionId may not return the session id
you expect (that is, the first one).
I know this because of a pathological environment we had a few years back:
1. Two contexts with nested URL patterns (/ and /foo)
2. Two contexts sharing a path prefix (/foo and /foo)
3. One of the two "shared-url" contexts did *not* use sessions, but
contacted the other "shared-url" webapp with the requested session id
form the request (you could think of it as "session forwarding")
Under this configuration, we could get ourselves into a situation
where the session id for the / webapp would be picked up by the
session-less webapp and forwarded to the third webapp. In that case
(and not every time, IIRC), the situation was only recoverable by
expiring all of the cookies and starting over again.
Bug reports were fantastically well-documented like "I was using your
site and it stopped working." Tough to investigate.
The moral of the story is that nested URL spaces is a bad idea where
sessions are concerned. We easily fixed that problem by moving the
/-mounted webapp to a unique URL prefix (which wasn't trivial, since
we had inter-webapp links, etc.) but it solved all of those weird
problems.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEAREIAAYFAlEyBZcACgkQ9CaO5/Lv0PDNYACePkVvMrqjm4BJqhjQjN78tILd
s1wAoLwrlcaVvpE9LzaGn8xYRMj2QMlW
=fQzr
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Multiple JSESSIONID
Posted by Nick Williams <ni...@nicholaswilliams.net>.
Browsers send all of the cookies because that's the compliant thing to do. RFC-2109 [1] says:
> If multiple cookies satisfy the criteria above, they are ordered in
> the Cookie header such that those with more specific Path attributes
> precede those with less specific. Ordering with respect to other
> attributes (e.g., Domain) is unspecified.
Based on that, assuming Tomcat follows the rules Christopher says it does, you should be okay. The /app/myapplication cookie should always come first, and assuming it is valid Tomcat should always prefer it.
Nick
[1] http://www.ietf.org/rfc/rfc2109.txt
On Mar 1, 2013, at 1:46 PM, Jose María Zaragoza wrote:
> Thanks for your answers.
>
> I wonder why browsers don't send only one JSESSIONID
> If I request an URL as www.mydomain.com/app/myapplication/action.do
> and it has got 2 cookies with the same name, one for www.mydomain.com/
> and another for www.mydomain.com/app/myapplication/ , IMHO, that a
> browser should send the most restrictive
>
> Indeed, I don't know if there is some browser working like that.
>
>
> Christopher,
> if the browser sends a JSESSIONID to Tomcat and this JSESSIONID is not
> tracked by the server , does any error happen ? or is it created a
> new session with a new identifier ?
>
> Thanks and regards
>
>
>
> 2013/2/28 Caldarale, Charles R <Ch...@unisys.com>:
>>> From: Nick Williams [mailto:nicholas@nicholaswilliams.net]
>>> Subject: Re: Multiple JSESSIONID
>>
>>>> That's interesting. I would recommend a servlet filter that captures
>>>> addCookie and friends to see where that "extra" one is being added.
>>
>>> The two JSESSIONIDs immediately above are in the request, so they're added
>>> by the browser, not the server
>>
>> Unless the browser is part of a hacking attack, the JSESSIONID cookies originally came from the server. The filter would have to be applied to both the ROOT and /app/myapplication contexts, so it might best be placed in conf/web.xml to cover all webapps.
>>
>> - Chuck
>>
>>
>> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
Re: Multiple JSESSIONID
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Jose,
On 3/1/13 2:46 PM, Jose María Zaragoza wrote:
> I wonder why browsers don't send only one JSESSIONID If I request
> an URL as www.mydomain.com/app/myapplication/action.do and it has
> got 2 cookies with the same name, one for www.mydomain.com/ and
> another for www.mydomain.com/app/myapplication/ , IMHO, that a
> browser should send the most restrictive
That would significantly limit the usefulness of cookies. The cookie's
"path" is really a path prefix. It would have been nice of the cookie
spec had been written so that clients sending a Cookie: header would
indicate the original path, but that's not the case so you have to
implement some workarounds sometimes.
> Indeed, I don't know if there is some browser working like that.
It would violate the spec, which probably means that MSIE can be
configured to behave as you describe.
> Christopher, if the browser sends a JSESSIONID to Tomcat and this
> JSESSIONID is not tracked by the server , does any error happen ?
> or is it created a new session with a new identifier ?
Tomcat ignores the session id unless a) the webapp (or a filter,
valve, etc.) requests the session or b) the server is configured to
strictly adhere to the servlet specification (or both). Sending an
invalid session id is not an error. If the session id is invalid and
the webapp requests a session, then a new session - with a new id -
will be created.
If the session id is invalid and strict spec compliance is enabled
(and the webapp does *not* specifically request the session), I
suspect the session id will be ignored entirely (but haven't tested
Tomcat under this configuration, nor have I read the code).
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEAREIAAYFAlEyAh0ACgkQ9CaO5/Lv0PC7WQCfUBpEyteBM1QnwDP60bD7E931
vbQAn38vJkmxS4Fd7mDRU/ORmIZ8XofD
=k4w/
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org