tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jerry Malcolm <techst...@malcolms.com>
Subject Re: Session Persistence Problems
Date Fri, 12 Apr 2019 15:14:54 GMT
Thanks, Luis.  I tried that.  And it indeed does store only one session 
cookie for the entire domain. But it does not change the fact that if 
you have two webapps in the same domain (contexts), you still have two 
different sessions and therefore two different session ids. You now just 
have one place to store both, and the cookie will always be replaced 
with id from the last call, throwing away the session id from the 
previous call.  When you call context A, the cookie is set to context A 
session id.  When you next call context B, the cookie is replaced with 
context B session id.  The you call context A again, it has to create a 
new session since it doesn't recognize context B's session id.    If it 
was possible to have all contexts share the SAME session (and session 
id), this would be perfect.  But from what I understand it is not 
possible to share the same session across multiple contexts.  Am I 
correct, or is there indeed a way to have one session for all contexts 
(not crosscontext access to other sessions... truly only ONE session 
used by all contexts)?

Jerry

On 4/12/2019 2:17 AM, Luis Rodríguez Fernández wrote:
> 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 (<techstuff@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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message