tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: Multiple JSESSIONIDs different subdomain
Date Tue, 22 Sep 2009 01:58:32 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rainer,

On 9/21/2009 5:23 AM, Rainer Jung wrote:
> On 21.09.2009 00:45, Christopher Schultz wrote:
>>
>> Struts will get whatever session Tomcat hands to it, so this is really a
>> Tomcat question: the current version of Tomcat will take all available
>> JSESSIONID cookie values and give you the one that matches a
>> currently-valid session. If none matches, I think you get an arbitrary
>> session id returned from request.getRequestedSessionId and if you call
>> getSession(true), you'll get a new session created.
> 
> ... and in the current implementation they should be tried in the order
> they are received from the client. Although I didn't find anything in
> the SPEC which mandates or suggests that.

Right, and there's nothing stopping your web browser from providing
those cookies in arbitrary order.

> If all fail, request.getRequestedSessionId() should return the value of
> the last cookie, i.e. the least specific. "Should" in the sense that's
> what I expect from current TC 6.0.x code, not in the sense of being the
> best choice.

Right: if Tomcat can't match /any/ of the JSESSIONID cookies to a valid
session, the return value for request.getRequestedSessionId is
arbitrary. Believe me, I got bitten by this when I had a Cocoon instance
trying to forward session ids back to the "real" application with which
it was sharing a URL space. We had a /third/ webapp sharing a URL space
(yeah, it was dumb, but backward compatibility had to be maintained at
least for a while) and they both were sending JSESSIONID cookies to
Cocoon. Since Cocoon had /no sessions at all/, it could never determine
which JSESSIONID cookie to send to the backend webapp.

The problem was only somewhat deterministic... it appeared that if you
visited our primary webapp first, then the secondary one, then Cocoon,
then all was well (Cocoon would contact the primary webapp "correctly").
If the secondary webapp was accessed first, then the primary one, then
Cocoon, Cocoon would fail because it would guess at the wrong JSESSIONID
cookie.

This was not reproduceable across all versions of all web browsers (I'm
pretty sure that MSIE didn't act like the others... surprise, surprise)
so we had no choice but to separate the URL spaces.

The lesson I learned: never deploy a web application as ROOT if you have
more than one web application to deploy. ;)

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkq4L0gACgkQ9CaO5/Lv0PCqowCfTf1V1J9wb+4vEUiR8MByjIDW
iQ0AoJSWIywgt3XJojbo/E7QsbhPBB9i
=eN9y
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message