Hello Jerry,
Sure, you can always set the path of your cookies to "/" via the
cookie-config element [1] in your web.xml descriptor:
<session-config>
<cookie-config>
<path>/</path>
</cookie-config>
</session-config>
Or via your context.xml [2]
Hope it helps,
Luis
[1]
https://javaee.github.io/servlet-spec/downloads/servlet-4.0/servlet-4_0_FINAL.pdf
[2] https://tomcat.apache.org/tomcat-9.0-doc/config/context.html
El vie., 12 abr. 2019 a las 0:14, Jerry Malcolm (<techst...@malcolms.com>)
escribió:
> 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
>
>
--
"Ever tried. Ever failed. No matter. Try Again. Fail again. Fail better."
- Samuel Beckett
