tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: Suggestions for overlapping URI spaces
Date Mon, 06 Aug 2007 17:27:10 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bill,

Bill Barker wrote:
> Enabling the RequestDumper to see if the browser is actually sending the 
> path would help.

Does the browser ever send the path?

Using LiveHTTPHeaders, I observed the following:

A = C08
B = 375

1. Visited the root-deployed application; server responds with
   credential challenge along with Set-Cookie header (cookie "A").
   Successful login, including client-sent cookie (path=/).
2. Visited the /foo application by attempting to access restricted
   resource. cookie A was presented by the client; 302 redirect to
   login page, including Set-Cookie (cookie "B") header (path=/foo).
3. /foo Login page requested by client, including "Cookie" header
   containing JSESSIONID=[B]; JSESSIONID=[A].
4. Credentials submitted to /foo/j_security_check, including Cookie
   header containing B; A.

No paths were ever sent by the client.

Both applications appear to work in this scenario. App /foo continues to
work. Perhaps due to the cookie ordering in the Cookie header. I'll
clear the cookies repeat the process in the opposite ordering.

B = E61
A = 858

0. Clear cookies from the entire site.
1. Attempt to access protected page in /foo; 302 response + Set-Cookie
   header (path=/foo) cookie "B".
2. /foo login page requested by client, including correct Cookie header.
3. Successful login; cookie is sent with all appropriate requests.
4. Request protected page in root-deployed application; no cookie sent
   by client. Server responds with Set-Cookie header (path=/) and 200
   response (no redirect for this app). This is Cookie A.
5. Submit login to /j_security_check; includes cookie A; successful
   login; cookie A is sent appropriately with all requests.
6. Re-load a protected page in /foo application; cookie header sent
   by client is in B; A order (same as last time).

Perhaps Mozilla Firefox is smart enough to order the cookies by
most-specific path. I happen to be using ff 2.0.0.6.

I have actually observed the improper behavior described in my OP in the
past, though I'm not sure if it was with ff 2.x or 1.5.x or even MSIE or
something else. I will have to investigate them separately.

> ATM, Tomcat simply assumes that the browser sends the 
> longest matching cookie (or at least sends the longest matching cookie 
> first) and doesn't send back the path.  If any significant browser is 
> sending the path back, then Tomcat could also pick the longest path cookie 
> as well.

Is that accurate? I haven't gone into the code myself (heh it's tough to
follow all the indirections in that stuff), but I wonder if TC actually
tries multiple cookies if they are presented. Like I said, I obviously
proved that access works appropriately in ff 2.0.0.6. Perhaps it is a
browser issue. Too bas the testing process is so tedious :(

>> 2. Change the session id cookie name in one of the apps (is this
>>   possible and/or recommended?)
>> 
> Not possible on TC without hacking the code.

That's what I thought. It's odd that the servlet spec demands that the
name of the cookie be JSESSIONID. I guess it's so that servlet
containers can be swapped-out more easily since the name of the cookie
won't change and disturb lb or other configuration, or filters and stuff
that might stupidly hard-code the cookie name (maybe that's not so
stupid...).

> 3. Use SSO -- except that I currently deploy these two applications
>   in separate Tomcat instances.
> 4. Re-deploy the root webapp to /bar and forward / to /bar.
> 
>> The browser should reject the '/' cookie in this case, since the URL that it 
>> sees doesn't start with '/bar'.

Of course. This is a sure-fire fix; it's just that it changes our URL
space and we need to be sensitive to our customers who expect to find
things under / instead of /bar.

Thanks for your thoughts, Bill.

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

iD8DBQFGt1nu9CaO5/Lv0PARAkIgAJ40KCobl7lnTFE1rUs4t+SRMb+gLACfdDZD
EeGpEkgwlm40vSO1sEPc3tg=
=MhLD
-----END PGP SIGNATURE-----

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


Mime
View raw message