-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Jerry,
On 4/11/19 18:05, Jerry Malcolm wrote: > On 4/11/2019 4:22 PM, Christopher Schultz wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >> >> Jerry, >> >> On 4/11/19 15:29, Jerry Malcolm wrote: >>> Alternatively, if I had a better understanding of how sessions >>> are managed by both TC and the browser, it might help me figure >>> out what is going wrong. I know a session key is generated by >>> TC and sent back in a response. And I'm assuming that the >>> browser must return that session key on subsequent calls. But >>> if there are several webapps on domain, how does the browser >>> differentiate which session key to send back on a subsequent >>> response? Is it just understood that the first 'folder' level >>> under the domain (i.e. context name) is always a different >>> session key? (myDomain.com/order vs. myDomain/account)? Or >>> does the browser send all session keys back per domain and let >>> TC figure out which one, if any, to use? Again, just looking >>> for a little education here.... >> Do you know if HTTP cookies or URL-parameters are being used for >> session-management? If you aren't sure, try logging-in to your >> application and look at the URLs and cookies. >> >> Typically, a web application will use cookies with the name >> JSESSIONID. If the session identifier is tracked in the URL, >> then you'll see ";jsessionid=[id]" in your URLs after the path >> but before the query string. >> >> It's very easy to "lose" a URL-tracked session id because every >> single URL generated by your application must include that >> parameter. A sinle miss can cause the session to be lost by the >> client. If you are using SSO (always with a cookie), it can mask >> the dropping of the session in this way. >> >> It's harder to "lose" a session cookie since the browser >> typically manages that. Cookies are tracked per web-application >> using each application's path. The browser should only return a >> single cookie for a given path. If you have applications that >> share a URL space (e.g. /master and /master/sub and /master/sub2) >> then things can get very confusing for the browser and the >> server. It's best not to overlap URL-spaces in this way. >> >> Are you using clustering or anything else like that which might >> also cause session-ids to change? >> >> - -chris > > Thank you so much for the info... I think we're getting > somewhere.... I am definitely using cookies and not url parms for > the session id. (no clustering). I went into the firefox debugger > and located the cookie storage for the site. I found a cookie for > each webapp context that I am using. That makes sense. I think I > know what is happening. Correct my assumptions here: > > I have a webapp with context /order. There is a JSESSIONID cookie > for /order as expected. I assume that every time I send a URL from > the browser with the /order context, the browser will correctly > send the /order session cookie. So far, so good... > > But.... I have a rewrite rule "/storefront" that maps to one of > the /order urls. Hmm... > I assume the browser knows nothing about rewrites, so the browser > is going to assume that "/storefront" is simply a different webapp > context that it doesn't have a session id cookie for, and therefore > doesn't send anything. Yes, exactly. > Therefore, when the rewritten url becomes another /order url, TC > gets an /order request but with no session id, and therefore > creates a new session and sends it back for the browser to store > (replace) as the /order session id. Correct. Had the rewrite been done as a REDIRECT, the browser would have made a second request which would have included the (correct) session cookie. Since your rewriting happens exclusively on the server-end, the cookie is not available. > So assuming I have analyzed this correctly, that can explain > precisely what I'm seeing. Understanding the problem is a big > step... But now I have to figure out how to get around it and make > it do what I want. At this point, I see three options: > > 1) remove all rewrites from httpd. That is going to be massive, > very difficult, and non-trivial. And I'll also have to come up > with way to handle multi-client variations, etc. that I have been > mapping by simply using different rewrites on each site. This one > is not even close to my first choice.... You may not have to give-up ALL rewrites. Just the problematic ones. you might even be able to convert the rewrites into redirects. That doesn't help you with SEO (lol) but it will take a broken application and make it work again without too much hassle. > 2) Could I perhaps send my own additional JSESSIONID cookies with > the current "/order" session id for the rewrite 'fake contexts' > such as "/storefront" so that the browser will basically send a > copy of the /order session id with the /storefront url? That would be very difficult to accomplish. You'd have to use a cookie path of / and then you'd conflict with your own existing session cookies and make things even more confusing. > 3) I really don't care to have separate sessions for each webapp > context anyway. In fact, I'd prefer it if there was one session / > sessionId for the enter application (all 10 contexts). Is there > any way to send the session id cookie keyed as simply "/" instead > of "/<context>"? Yes, but it won't do what you want it to do. It will probably just cause more confusion. > All URLs to the domain whether rewrite aliases or actually urls > would match this one JSESSIONID cookie and therefore would always > send the JSESSIONID. If that would work, that would solve > everything and all rewrites would still work as they do now.> > Recommendation for which way to go? #3 is my favorite (but I like > to dream...). But if #2 will work, I'll go with it. Just > desperately trying to prevent having to do #1.... How many of these boundary-crossing (or boundary-hiding?) URL rewrites do you have. You said you have lots of rewrites, but how many of them change the top-level path? - -chris -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlyw6BMACgkQHPApP6U8 pFjMyg//drBGgqyUZwA3aAq5duMgyZ6r6axkEjoP7p6b5Oibmpj68dUQr75/va0b uxELZ1199BJHvAtF2C2jXsbVmJBTyA/K5OYBrgX40TzWY2SUjMSqqjOfxhCNwb7N H0QPOp0bjqakMs31jWMQtP0kCOMv+UimlL8XWoOocGVRIP7y90EIST5X7EukrpNY U63mtu9K+StjwHvb38GcQLwdwWSus5iEsd1w0/4uwp4b6URDaJNZfhSrZ46yI0Mc onbNDCi80ln/HXvQdH+zT9Oo8VVjtLdLDMA0mIw1V0JiPCmTZMKuKJDaluHpNRW2 vRQOsCPsgMtyVOqZC5pK50OqIKuQEWmRgAqoz047l5xq5v005Jw3rQ2xmUei6XFp m/eKsmYI42LglSgvJEJZa/T9RmiWFDGZ54MoEexGAltZoNhT/O+HmxIBz0CzfJHa E6kH1kuAf+66k5eW3S307czUwujphJL189y5Hv+7Qx+iVi8mtS+oLzcq4nUv9UdW nAW7buMaf+mqhsfJUFuM+N4TQHVTkDk/xfTxAQ6Ok96Vmw3XYd8bfLn2gnn8wKrb WM5B6cBFPCtG8RfcehR7Cnxn2yn9VksxU44wLFXetPLvPU3t0OW3LHNjWZ1tq+iG PY/46oHgYz9wZGgM8THL8rTsEfKLSj33Kn4Hepd4X38raezENq0= =jy7c -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
