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. 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. 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.
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....
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?
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>"? 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....
Thanks again for all the help.
Jerry
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
