tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: How does one control what the path is on the JSESSIONID cookie?
Date Fri, 26 Jun 2009 18:15:24 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John,

On 6/24/2009 3:05 PM, John Caron wrote:
> Christopher Schultz wrote:
>> [...]
>> That said, having overlapping webapp URL spaces is asking for trouble.
>>   
> Sorry, I didnt explain much context. This isnt for browsers, its a
> specialized web service for specialized clients. I have control of both
> the client and the server code. The clients are accessing remote
> scientific datasets. In certain circumstances, establishing a session
> with them for each dataset that they open solves some hard problems.

What about using URLs with jsessionid encoded directly, rather than
using cookies? If you control the client, this may be a much more
manageable strategy.

> Im hoping to not use Valves since that makes my code Tomcat specific. I
> am delivering this webapp to some dozens of scientific institutions.
> Allowing them to run any servlet container is a big win.

This is always a good strategy to follow. We can probably come up with
something.

> I have rewritten this as follows:

The problem with filters is that they are applied relatively /late/ in
request processing. Even if this is the first filter executed, the
container-based authenticator is running /before/ this, and is likely to
create a cookie for session tracking. Attempting to change the cookies
properties after that might not work at all.

> However, it has no effect, the path stays equal the web context name.

What does the actual HTTP response look like?

> Im
> guessing there some code that rejects changing the session cookie ( I
> havent tracked it yet in the debugger). Is this a security thing or is
> there something in the Servlet spec that says what the path has to be?

It's more likely that both cookies are being returned to the client (no
prohibition against that) and that your client is arbitrarily choosing
one of them.

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

iEYEARECAAYFAkpFEDsACgkQ9CaO5/Lv0PA34QCfdTakV9X3qsqi+0dhMBN41QPh
FSwAnA/8P7r6Oknh3822pZZHpUTXay+D
=KLDI
-----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