"Christopher Schultz" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > -----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? >
I've never seen one that did, and since TC sends the Session cookie as version 0, most browsers would likely assume that TC doesn't understand version 1 cookies. > 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 :( > The session cookie stuff is only in CoyoteAdapter. It loops over the cookies, and sets the requestedSessionId on the Request to the first one that it finds (killing the one from ;jsessionid=, if sent). For any other JSESSIONID cookie that it finds, it checks request.isRequestedSessionIdValid, and if not, sets the value to this cookie. So assuming that the browser is sending longest-first, you could see what you claim if the /foo session timed out or was otherwise invalidated. >>> 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] > > --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
