tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: Session Persistence Problems
Date Fri, 12 Apr 2019 19:33:39 GMT
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message