Re: Suggestions for overlapping URI spaces
-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]
Re: Suggestions for overlapping URI spaces
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
RE: Suggestions for overlapping URI spaces
To be honest I'm not sure how you are getting this right, its probably best to use separate namespaces though, then you can use URL rewriting to make them appear as one, this solution is really powerfull, we use it to integrate all our apps in our domain, we even integrate Java and Perl apps using Apache mod_rewrite, there is a similar module for tomcat called tuckey http://tuckey.org/urlrewrite/ Peter -Original Message- From: Christopher Schultz [mailto:[EMAIL PROTECTED] Sent: Fri 8/3/2007 8:16 PM To: Tomcat Users List Subject: Suggestions for overlapping URI spaces -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 All, I have two applications deployed in production that share a URL space. Actually, one is deployed as the root webapp, the the other one is at, say, /foo. My problem is that each webapp maintains its own session identifiers as cookies. Since the session id cookie is always called JSESSIONID, a visitor who uses both applications gets two cookies (one with /, and one with /foo) with different JSESSIONID values. I'm guessing that Tomcat doesn't try to pick the best one, since things get /really/ confusing when this happens. Basically, our users get caught in a continuous please-login - login - please-login - login loop. It appears that the root JSESSIONID is being preferred over the more recent /foo one, which is never read properly so the login can never happen. Does anyone have any suggestions for how to fix this? Some obvious ideas are: 1. Don't do that. 2. Change the session id cookie name in one of the apps (is this possible and/or recommended?) 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. I'm just looking for the right solution. Any comments or suggestions would be appreciated. Thanks, - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGs38V9CaO5/Lv0PARApHzAKCqMrz2AntBJDAosgUkd5iBzBZVRwCglY2m SlO68LvbodFxNLWIoObTorQ= =KdXa -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]
Suggestions for overlapping URI spaces
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 All, I have two applications deployed in production that share a URL space. Actually, one is deployed as the root webapp, the the other one is at, say, /foo. My problem is that each webapp maintains its own session identifiers as cookies. Since the session id cookie is always called JSESSIONID, a visitor who uses both applications gets two cookies (one with /, and one with /foo) with different JSESSIONID values. I'm guessing that Tomcat doesn't try to pick the best one, since things get /really/ confusing when this happens. Basically, our users get caught in a continuous please-login - login - please-login - login loop. It appears that the root JSESSIONID is being preferred over the more recent /foo one, which is never read properly so the login can never happen. Does anyone have any suggestions for how to fix this? Some obvious ideas are: 1. Don't do that. 2. Change the session id cookie name in one of the apps (is this possible and/or recommended?) 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. I'm just looking for the right solution. Any comments or suggestions would be appreciated. Thanks, - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGs38V9CaO5/Lv0PARApHzAKCqMrz2AntBJDAosgUkd5iBzBZVRwCglY2m SlO68LvbodFxNLWIoObTorQ= =KdXa -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]
Re: Suggestions for overlapping URI spaces
Christopher Schultz [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 All, I have two applications deployed in production that share a URL space. Actually, one is deployed as the root webapp, the the other one is at, say, /foo. My problem is that each webapp maintains its own session identifiers as cookies. Since the session id cookie is always called JSESSIONID, a visitor who uses both applications gets two cookies (one with /, and one with /foo) with different JSESSIONID values. I'm guessing that Tomcat doesn't try to pick the best one, since things get /really/ confusing when this happens. Basically, our users get caught in a continuous please-login - login - please-login - login loop. It appears that the root JSESSIONID is being preferred over the more recent /foo one, which is never read properly so the login can never happen. Does anyone have any suggestions for how to fix this? Some obvious ideas are: Enabling the RequestDumper to see if the browser is actually sending the path would help. 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. 1. Don't do that. 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. 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'. I'm just looking for the right solution. Any comments or suggestions would be appreciated. Thanks, - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGs38V9CaO5/Lv0PARApHzAKCqMrz2AntBJDAosgUkd5iBzBZVRwCglY2m SlO68LvbodFxNLWIoObTorQ= =KdXa -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]
