-----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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
