You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Jerry Malcolm <te...@malcolms.com> on 2019/04/11 03:56:56 UTC
Session Persistence Problems
I have a TC host that is running about 10 separate webapps that interact
with each other. I understand that sessions are per-webapp. But within
one webapp, with the same browser just making different calls to the
same webapp is starting new sessions about 30% of the time. I've put a
debug statement at the beginning of all of my JSPs that logs
session.isNew(). It'll start a new session, then use it for 10 or so
subsequent calls. But then it'll decide to drop that session and start a
new one that it'll subsequently use for a while. The setup is nothing
fancy. It's just calling several different JSPs within the same webapp
(context). I am keeping data in the session that really needs to
persist for the duration of the 'real' session between the user and the
site. So this is a serious problem. (This is happening both with
Firefox and Chrome). I'm using TC 9.0.1 on Windows.
I definitely could have some misunderstandings here. But my first
understanding is that once a browser makes a call to a webapp, a session
is created, and that session remains around until invalidated on a
logout or a timeout occurred, and that webapp uses that session for the
remainder of the activity between that browser and that webapp. If
that's not the case, then please set me straight. If that assumption is
correct, what could possibly be causing the sessions to keep dropping
and new ones created?
Interestingly, logon state is not being dropped with the new sessions.
I'm using single sign-on. So that may be ensuring the logon doesn't drop.
The only thing I can come up with is that I'm using some RewriteRules in
httpd to map the complex url paths to single words like "/product". (SEO
advisor told me to do that...) I'm trying to see in the logs if there is
a correlation between rewrites and the new sessions. But I can't really
tell if that's what's causing it.
Am I missing or do I have some sort of errant configuration setting that
is causing the sessions to keep reinitiating? Is there something else
I'm missing? I really need to have sessions that last as long as the
user is on the site.
Suggestions? Help??
Thx.
Jerry
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] Session Persistence Problems
Posted by "André Warnier (tomcat)" <aw...@ice-sa.com>.
On 11.04.2019 22:56, Jerry Malcolm wrote:
>
> On 4/11/2019 3:11 PM, Christopher Schultz wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA256
>>
>> Jerry,
>>
>> On 4/10/19 23:56, Jerry Malcolm wrote:
>>> The only thing I can come up with is that I'm using some
>>> RewriteRules in httpd to map the complex url paths to single words
>>> like "/product". (SEO advisor told me to do that...)
>> Do you allow crawlers to crawl the authenticated parts of your
>> application? If not, then you are wasting your time with all that.
>>
> Only a portion of the site is authenticated. But whether or not it is an SEO advantage, I
> use this to customize the precise URL for different clients who use the same code on
> different domains. /product maps to a slightly different URL for clientA on domain A
> installation vs for clientB on domain B installation. So without some signification
> recoding, I need to keep using rewrites.
>
> But whether the merits are there for doing rewrites, the only thing I am concerned about
> is if doing rewrites is causing my sessions to mess up. Hence my question about how the
> browser and TC decide what session key to use for a particular url.
>
I honestly don't know. But searching Google for "java sessions" seems to provide quite a
few links to enlighten one on the matter.
Just looking at the titles, it does not seem to be Tomcat-related or browser-related per
se, and more related to Java itself, or more probably to the Java Servlet Specification
(which is also found easily in the web).
(See e.g. : https://javaee.github.io/servlet-spec/downloads/servlet-4.0/servlet-4_0_FINAL.pdf
Chapter 7 : sessions)
(ok, Chapter 7, item 7.1.1 Cookies, also says
"Containers may allow the name of the session tracking cookie to be customized
through container specific configuration."
So I guess that something in there may be specific to Tomcat also.
Back to the Tomcat docs then.
Hmm. Not particularly easy to find "sessions" in there, but I found this :
http://tomcat.apache.org/tomcat-9.0-doc/config/context.html#Attributes
Look at "sessionCookieName".
So it looks like you can, at the level of a Context (in other words, one webapp), set the
cookie name into which to save the session-id for that webapp.
That seems to go some way into answering your question.
In any case, like me just now, it seems that you're gonna learn something about sessions..
(Note: It /is/ also browser-related, but probably only because the (any) browser will
"remember" the cookies sent by an application, and return them to the server each time the
browser accesses that same server later. And because such Java session-id's, most of the
time, are stored in cookies). If I remember well, most of the time, such a cookie has the
name "JSESSIONID". In the browser, find the place were you can view the cookies, and
search for the ones related to your application server (by DNS name). Then look at the
cookies which your browser stores for that site.
>>
>
> ---------------------------------------------------------------------
> 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
Re: [OT] Session Persistence Problems
Posted by Jerry Malcolm <te...@malcolms.com>.
On 4/11/2019 3:11 PM, Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Jerry,
>
> On 4/10/19 23:56, Jerry Malcolm wrote:
>> The only thing I can come up with is that I'm using some
>> RewriteRules in httpd to map the complex url paths to single words
>> like "/product". (SEO advisor told me to do that...)
> Do you allow crawlers to crawl the authenticated parts of your
> application? If not, then you are wasting your time with all that.
>
Only a portion of the site is authenticated. But whether or not it is
an SEO advantage, I use this to customize the precise URL for different
clients who use the same code on different domains. /product maps to a
slightly different URL for clientA on domain A installation vs for
clientB on domain B installation. So without some signification
recoding, I need to keep using rewrites.
But whether the merits are there for doing rewrites, the only thing I am
concerned about is if doing rewrites is causing my sessions to mess up.
Hence my question about how the browser and TC decide what session key
to use for a particular url.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] Session Persistence Problems
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Jerry,
On 4/10/19 23:56, Jerry Malcolm wrote:
> The only thing I can come up with is that I'm using some
> RewriteRules in httpd to map the complex url paths to single words
> like "/product". (SEO advisor told me to do that...)
Do you allow crawlers to crawl the authenticated parts of your
application? If not, then you are wasting your time with all that.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlyvn20ACgkQHPApP6U8
pFhgCw/+OToWJ/UyBipLetc810tAzTJdar0pbYaZJf6XKIkigg/4SFE1gfRa2PfQ
IbwylPMTXSAASeHqNfXYB/E28DD//h0LseRPPLjDFERC9msoOxIt53mqps4TGwEa
vVrefMU7+YSlXCBqkEZL1vLjGqHA2uEVpfskHlIO9Zx7BDWCmYQ6slEPpdOLml68
6lk2ESKapCTO46XxNud6kfIs4zulmudq+emWLenouZBroPlUb9MmRBM1wBwWh4o5
TE0x3v7MKJVXnCJPOFacWIF5deMjzYqKsEvjlAZnQfbxUFP/tKzUskQctwuCNg3J
W8ngrAbmFydJUVWaOEO9On5cDhrG65gX3TX9kRFsRKSn5Q3fTo4lRkSP6AAlGqr5
oy4Eq4lFuspZWa1oFE0fTjPP/TuumqHJAGMR6FGnBrlx7kr23E+efUGddUbw0/+U
RWCe0f06uNVw2KvGxIHx/l5Gm7AgxHQIzjuJHMcaToyr7r6eZ8OdGzfGV8oljuXZ
eCiigghmVe8C974mIs+u/DgS7YXHDB/bbyOgXMVqigFixsnp87sU3+H0pb2Y9epj
5vwMRhaGZf/Srkq4dT+9C7jf4J1CamXeXkBEjuBA+revG4Aj+TxeMKkVU4llNa8t
nscG6dnjSv3ut3e2E5DGT23+TGQuZSZ4NtVaZGZgbqfxt36f1eU=
=EWdf
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Session Persistence Problems
Posted by John Dale <jc...@gmail.com>.
I'm looking forward to hearing from the dev folks on this. I suspect
it has something to do with the context configuration.
A long time ago, I started doing my own session management, but then I
don't mind building out the pieces I needed for clustering. In fact,
I decided to store session information in the database (persistent).
That makes scaling easy.
On 4/11/19, Jerry Malcolm <te...@malcolms.com> 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....
>
> Thx.
>
> Jerry
>
> On 4/11/2019 9:35 AM, Jerry Malcolm wrote:
>> Thanks for the quick response, Luis. Answers below:
>>
>> On 4/11/2019 3:22 AM, Luis Rodríguez Fernández wrote:
>>> Hello Jerry,
>>>
>>>> I'm using single sign-on
>>> Do you mean tomcat Single Sign On valve? [1], a third party solution or
>>> your custom implementation? That can change the game completely :)
>> Yes, standard Tomcat-provided single sign on valve
>>>
>>>> some RewriteRules in httpd
>>> Can you share them? That could change the game also :)
>>
>> Here's some of my rewrite rules from httpd.conf for this virtualhost:
>>
>> RewriteRule ^/create_user$
>> /idmanager/jsp/guest/createuser.jsp? [PT]
>> RewriteRule ^/forgot_password$
>> /idmanager/jsp/guest/forgotpassword.jsp? [PT]
>> RewriteRule ^/logoff$ /idmanager/jsp/guest/logoff.jsp [PT]
>> RewriteRule ^/change_password$
>> /idmanager/jsp/user/changepassword.jsp? [PT]
>> RewriteRule ^/login$ /idmanager/jsp/user/home.jsp [PT]
>> RewriteRule ^/userhome$ /idmanager/jsp/user/home.jsp? [PT]
>> RewriteRule ^/cart$ /order/jsp/guest/cart.jsp? [PT,QSA]
>> RewriteRule ^/checkout$ /order/jsp/guest/checkout.jsp? [PT]
>> RewriteRule ^/submitOrder$ /order/jsp/guest/orderSubmit.jsp?
>> [PT,QSA]
>> RewriteRule ^/displayImage$ /order/jsp/guest/productPage.jsp?
>> [PT,QSA]
>> RewriteRule ^/product$ /order/jsp/guest/productPage.jsp?
>> [PT,QSA]
>> RewriteRule ^/storeFront$ /order/jsp/guest/storeFront.jsp [PT]
>> RewriteRule ^/orders$ /order/jsp/user/orderList.jsp? [PT]
>> RewriteRule ^/pay$ /payment/jsp/user/flcPayProvision.jsp [PT]
>> RewriteRule ^/projectlist$
>> /projectmanager/jsp/user/projectlist3.jsp? [PT]
>> RewriteRule ^/about$ /upartyrental/jsp/guest/about.jsp? [PT]
>> RewriteRule ^/$ /upartyrental/jsp/guest/uprHome.jsp [PT]
>>
>>>
>>> Cheers,
>>>
>>> Luis
>>>
>>> [1]
>>> https://tomcat.apache.org/tomcat-9.0-doc/config/valve.html#Single_Sign_On_Valve
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> El jue., 11 abr. 2019 a las 5:57, Jerry Malcolm
>>> (<te...@malcolms.com>)
>>> escribió:
>>>
>>>> I have a TC host that is running about 10 separate webapps that
>>>> interact
>>>> with each other. I understand that sessions are per-webapp. But within
>>>> one webapp, with the same browser just making different calls to the
>>>> same webapp is starting new sessions about 30% of the time. I've put a
>>>> debug statement at the beginning of all of my JSPs that logs
>>>> session.isNew(). It'll start a new session, then use it for 10 or so
>>>> subsequent calls. But then it'll decide to drop that session and
>>>> start a
>>>> new one that it'll subsequently use for a while. The setup is nothing
>>>> fancy. It's just calling several different JSPs within the same webapp
>>>> (context). I am keeping data in the session that really needs to
>>>> persist for the duration of the 'real' session between the user and the
>>>> site. So this is a serious problem. (This is happening both with
>>>> Firefox and Chrome). I'm using TC 9.0.1 on Windows.
>>>>
>>>> I definitely could have some misunderstandings here. But my first
>>>> understanding is that once a browser makes a call to a webapp, a
>>>> session
>>>> is created, and that session remains around until invalidated on a
>>>> logout or a timeout occurred, and that webapp uses that session for the
>>>> remainder of the activity between that browser and that webapp. If
>>>> that's not the case, then please set me straight. If that assumption is
>>>> correct, what could possibly be causing the sessions to keep dropping
>>>> and new ones created?
>>>>
>>>> Interestingly, logon state is not being dropped with the new sessions.
>>>> I'm using single sign-on. So that may be ensuring the logon doesn't
>>>> drop.
>>>>
>>>> The only thing I can come up with is that I'm using some
>>>> RewriteRules in
>>>> httpd to map the complex url paths to single words like "/product".
>>>> (SEO
>>>> advisor told me to do that...) I'm trying to see in the logs if
>>>> there is
>>>> a correlation between rewrites and the new sessions. But I can't
>>>> really
>>>> tell if that's what's causing it.
>>>>
>>>> Am I missing or do I have some sort of errant configuration setting
>>>> that
>>>> is causing the sessions to keep reinitiating? Is there something else
>>>> I'm missing? I really need to have sessions that last as long as the
>>>> user is on the site.
>>>>
>>>> Suggestions? Help??
>>>>
>>>> Thx.
>>>>
>>>> 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
Re: Session Persistence Problems
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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
Re: Session Persistence Problems
Posted by Jerry Malcolm <te...@malcolms.com>.
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 (<te...@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
Re: Session Persistence Problems
Posted by Luis Rodríguez Fernández <uo...@gmail.com>.
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 (<te...@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
>
>
--
"Ever tried. Ever failed. No matter. Try Again. Fail again. Fail better."
- Samuel Beckett
Re: Session Persistence Problems
Posted by John Dale <jc...@gmail.com>.
This is a great information.
I'd like to stray a little off topic if that's okay .. still in the
same ballpark.
I like to invent new doodads in software and see if I can do it better.
Over the years, like many, I built-up a library of things that worked
best for me over the years. One of those was the delegation of
context management to my own code. I have Alias and Domain objects in
my database that allow me to map URL's to domains (HTML5 applications
that use some really lightweight server side JSON components). It
works great and I can change configuration by updating the database.
Awesome for deployment and configuration management.
For now, I put a "deviceId" in localStorage on the browser (I'm only
concerned in supporting modern browsers), and I send that with every
request. Device is an object in my database as well, and I look up
the device ID at the start of processing, which then can be associated
with any number of other data/field level security measures. Rest
assured, now, I've worked all this out, and I have developed dozens of
applications that all work great. I could move deviceId to the header
if I wanted to, or maybe a cookie. So far, I like it, it's fast, it's
simple, and works great to solve session affinity problems.
Local storage is mapped to the root domain, so I have access to my
deviceId regardless of the context.
My question is this .. how could this come back to bite me? I've
enjoyed the convenience of SSO for all contexts deployed under a
particular domain, but I would have a little code to write to do
single sign on across domains because of the way the browser manages
localStorage (I would do a simple token exchange to SSO, but I haven't
had that use case, yet).
I have always struggled to shoe-horn some of the session management
into my (sometimes admittedly advanced and unpredictable) application
requirements.
Would love to hear your thoughts.
Have a good one,
John
DB2DOM.COM
On 4/11/19, Jerry Malcolm <te...@malcolms.com> 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. 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
Re: Session Persistence Problems -- Epilog
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Jerry,
On 4/11/19 19:34, Jerry Malcolm wrote:
>
> On 4/11/2019 5:05 PM, 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. 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
>
> I found the 'perfect' answer to my problem (I thought) in some
> comment on the web. It said simply add:
>
> <cookie-config> <path>/</path> </cookie-config>
>
> to web.xml. That did just what I suggested in option 3, and stored
> only one JSESSIONID cookie using path "/". But (keep
> reading....).... what it didn't tell you is that even though you
> store only one session id, it makes it worse since the same session
> id is sent to all contexts, both the one that created it and all
> other contexts that did not create it... BUT one context can't see
> the session created by another context. So you are basically
> sending a different context's sessionid to this session, which it
> doesn't recognize. So it creates a new one and sends it back as
> the 'one and only' session. Bottom line.... the problem just got
> worse, with just about every request creating a new session. I
> really would like to know what possible benefit it would be to use
> the above code in a multi-context application. But that is a
> question for another day.... Certainly NOT a solution I can use.
>
> On to option 2.... success. I have a header file for each webapp
> that is included at the top of all JSPs. I simply went into that
> header for each context, and added JSESSIONID cookies with the
> value of the current sessionId and the path for each of the 'alias
> rewrites' that map to that webapp. So there is now a JSESSIONID
> cookie for /storeFront that is the same value as /order, and hence
> when I call /storeFront from the browser it will send the correct
> sessionId for /order which will make the /order context webapp
> happy.
>
> I will need to maintain the rewrite-cookie list in my jsp header
> files to make sure there is an entry to match all rewrite aliases
> defined in httpd that map to that context. But.... it works.
At first, I was actually surprised to see that the browser allowed you
to save a cookie for a "different application root path" but then I
remembered that the browser has no idea what a "context" is and you
can set any path you'd like. You can't set a cookie on /another
domain/ but you can pick another path on your same domain.
So if you have a strict "aliasing" of top-level paths, then this
solution will probably work long-term.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlyw6S0ACgkQHPApP6U8
pFhOHA/9H7Xc/+wCNnBidDZIhlXwUDxya2+wdcLGADJWeafX+O5/DNiSuUmb2i0k
9TKu6e7HJeJQjNSYECRF1dKAmSmR1Ceiq/2SYO/1pHrBXa9HZH2VTp7vzvCXLIKG
l5LXH/nAFPQ8sSRMZcTiUMBC7OtGpcG40VIQ9sKlhB3CmFsUauIjWOM8aHXDXHVB
1XpWCFNT1kCwsrfla6dwJymK+mcW+Tz9oqOT/uCeYvl7HstCD4PsErtvDAmdNgyo
Gnnet5Af3+kqoeVKOJa/MhwtFhLRrQZK1Ru3wth87JRdxlMhmE4kPceYWQW/20Z6
oJ/fzcolplsNwGByqLua2GWadKG0Za5+ENpW6OhkQpnSF/CoZp9JafiTEE6x+wYF
wJAfB4Gnm4XaiAGYn8tjx0w7qLvtGbIQB3gDmULLMNyxdwXZwiM8ddrlPEAjgOvp
cUYc3q+sdASVfktXNrJ0MSLLDFeMRh+673Sam8XiszUHtdCH+WOUFRTrW6Q6EZii
J6rx/GBsMiL7fk1Bv4rWPn6JgyDIws8VjxYfawAUj3iSN8qPLXrfLcMdeDR3rf64
zUMIldYSXyBOKXzO+q2NTy2+aegguFNIWgk60IWPUcSDm2jdTylCmI+NbV35HT+e
A1bNa7qPEyDO2OcvxnXY2W7Oq799xmXSMYfylbwwoVBWIO3Ppj0=
=bzhS
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Session Persistence Problems -- Epilog
Posted by Jerry Malcolm <te...@malcolms.com>.
On 4/11/2019 5:05 PM, 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. 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
I found the 'perfect' answer to my problem (I thought) in some comment
on the web. It said simply add:
<cookie-config>
<path>/</path>
</cookie-config>
to web.xml. That did just what I suggested in option 3, and stored only
one JSESSIONID cookie using path "/". But (keep reading....).... what
it didn't tell you is that even though you store only one session id, it
makes it worse since the same session id is sent to all contexts, both
the one that created it and all other contexts that did not create it...
BUT one context can't see the session created by another context. So
you are basically sending a different context's sessionid to this
session, which it doesn't recognize. So it creates a new one and sends
it back as the 'one and only' session. Bottom line.... the problem just
got worse, with just about every request creating a new session. I
really would like to know what possible benefit it would be to use the
above code in a multi-context application. But that is a question for
another day.... Certainly NOT a solution I can use.
On to option 2.... success. I have a header file for each webapp that
is included at the top of all JSPs. I simply went into that header for
each context, and added JSESSIONID cookies with the value of the current
sessionId and the path for each of the 'alias rewrites' that map to that
webapp. So there is now a JSESSIONID cookie for /storeFront that is the
same value as /order, and hence when I call /storeFront from the browser
it will send the correct sessionId for /order which will make the /order
context webapp happy.
I will need to maintain the rewrite-cookie list in my jsp header files
to make sure there is an entry to match all rewrite aliases defined in
httpd that map to that context. But.... it works.
On to the next problem.
Thanks for the help and allowing me to talk this through and get an
acceptable solution.
Jerry
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Session Persistence Problems
Posted by Jerry Malcolm <te...@malcolms.com>.
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
Re: Session Persistence Problems
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlyvr/kACgkQHPApP6U8
pFg4KBAAi0qYZDxX0TGApjLOhwTqtP3u22tT9+JXEjcwylIfx+WaURgNTTgEUQQJ
rJMkwBBugCU1cgusveBsAJUtuDhe9QMkmx0BKI4JF12hzy+nk8BN/yC0crcvfgfz
NIfHWOHV2eczu5ZMDaYeyYOiUM27b+k4Xl0YR0xRtYeJ7/HdnxaklfPojXzFNUhJ
vRa6GSjtgCI6JcW+eHPy5T2OmLtdYatHcY+S9qtOJvNsf3mf1WFDHCV6iHR+9NTP
2artOzKAOWe/HLoKo9h8tjSuzgMrodE2dnzdu/DUs1JJjDLl5INXp7WXR6z5BshB
oK/op5+e7dV/7BONc9HHEh/99kivgEu86DQ3H6OfQF2+oNVy5kuyzY12/OMvJusg
oppLZYV6XCVAUduwkP5W1SjBJWjDuUkQwtSRQ6O2Vren1wI3GIZtSvfZHygEM2Ht
X67QyMLJQEh9yZedtdUF9gGJzkREnibxScBtFJc4HpuBezs1HQ4eOk2WTnTpmiAL
w38IEM6b/9snSzHcqxXSkkx3vZjf3EuEfZKJwymzC5iHADo6KZsW+aYB4dzrFoJa
E5xtJRKZT5i5CHLr7l5bmV4QifZrQa50UA47fe+KvfQiQJW5xZG2lTFl2as6bNGW
4EgcPk6yHDVaGF4xqBN84kp1fqJ++G0c32b/Ogm0Hwfm/ShOvCc=
=9pTl
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Session Persistence Problems
Posted by Jerry Malcolm <te...@malcolms.com>.
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....
Thx.
Jerry
On 4/11/2019 9:35 AM, Jerry Malcolm wrote:
> Thanks for the quick response, Luis. Answers below:
>
> On 4/11/2019 3:22 AM, Luis Rodríguez Fernández wrote:
>> Hello Jerry,
>>
>>> I'm using single sign-on
>> Do you mean tomcat Single Sign On valve? [1], a third party solution or
>> your custom implementation? That can change the game completely :)
> Yes, standard Tomcat-provided single sign on valve
>>
>>> some RewriteRules in httpd
>> Can you share them? That could change the game also :)
>
> Here's some of my rewrite rules from httpd.conf for this virtualhost:
>
> RewriteRule ^/create_user$
> /idmanager/jsp/guest/createuser.jsp? [PT]
> RewriteRule ^/forgot_password$
> /idmanager/jsp/guest/forgotpassword.jsp? [PT]
> RewriteRule ^/logoff$ /idmanager/jsp/guest/logoff.jsp [PT]
> RewriteRule ^/change_password$
> /idmanager/jsp/user/changepassword.jsp? [PT]
> RewriteRule ^/login$ /idmanager/jsp/user/home.jsp [PT]
> RewriteRule ^/userhome$ /idmanager/jsp/user/home.jsp? [PT]
> RewriteRule ^/cart$ /order/jsp/guest/cart.jsp? [PT,QSA]
> RewriteRule ^/checkout$ /order/jsp/guest/checkout.jsp? [PT]
> RewriteRule ^/submitOrder$ /order/jsp/guest/orderSubmit.jsp?
> [PT,QSA]
> RewriteRule ^/displayImage$ /order/jsp/guest/productPage.jsp?
> [PT,QSA]
> RewriteRule ^/product$ /order/jsp/guest/productPage.jsp?
> [PT,QSA]
> RewriteRule ^/storeFront$ /order/jsp/guest/storeFront.jsp [PT]
> RewriteRule ^/orders$ /order/jsp/user/orderList.jsp? [PT]
> RewriteRule ^/pay$ /payment/jsp/user/flcPayProvision.jsp [PT]
> RewriteRule ^/projectlist$
> /projectmanager/jsp/user/projectlist3.jsp? [PT]
> RewriteRule ^/about$ /upartyrental/jsp/guest/about.jsp? [PT]
> RewriteRule ^/$ /upartyrental/jsp/guest/uprHome.jsp [PT]
>
>>
>> Cheers,
>>
>> Luis
>>
>> [1]
>> https://tomcat.apache.org/tomcat-9.0-doc/config/valve.html#Single_Sign_On_Valve
>>
>>
>>
>>
>>
>>
>>
>>
>> El jue., 11 abr. 2019 a las 5:57, Jerry Malcolm
>> (<te...@malcolms.com>)
>> escribió:
>>
>>> I have a TC host that is running about 10 separate webapps that
>>> interact
>>> with each other. I understand that sessions are per-webapp. But within
>>> one webapp, with the same browser just making different calls to the
>>> same webapp is starting new sessions about 30% of the time. I've put a
>>> debug statement at the beginning of all of my JSPs that logs
>>> session.isNew(). It'll start a new session, then use it for 10 or so
>>> subsequent calls. But then it'll decide to drop that session and
>>> start a
>>> new one that it'll subsequently use for a while. The setup is nothing
>>> fancy. It's just calling several different JSPs within the same webapp
>>> (context). I am keeping data in the session that really needs to
>>> persist for the duration of the 'real' session between the user and the
>>> site. So this is a serious problem. (This is happening both with
>>> Firefox and Chrome). I'm using TC 9.0.1 on Windows.
>>>
>>> I definitely could have some misunderstandings here. But my first
>>> understanding is that once a browser makes a call to a webapp, a
>>> session
>>> is created, and that session remains around until invalidated on a
>>> logout or a timeout occurred, and that webapp uses that session for the
>>> remainder of the activity between that browser and that webapp. If
>>> that's not the case, then please set me straight. If that assumption is
>>> correct, what could possibly be causing the sessions to keep dropping
>>> and new ones created?
>>>
>>> Interestingly, logon state is not being dropped with the new sessions.
>>> I'm using single sign-on. So that may be ensuring the logon doesn't
>>> drop.
>>>
>>> The only thing I can come up with is that I'm using some
>>> RewriteRules in
>>> httpd to map the complex url paths to single words like "/product".
>>> (SEO
>>> advisor told me to do that...) I'm trying to see in the logs if
>>> there is
>>> a correlation between rewrites and the new sessions. But I can't
>>> really
>>> tell if that's what's causing it.
>>>
>>> Am I missing or do I have some sort of errant configuration setting
>>> that
>>> is causing the sessions to keep reinitiating? Is there something else
>>> I'm missing? I really need to have sessions that last as long as the
>>> user is on the site.
>>>
>>> Suggestions? Help??
>>>
>>> Thx.
>>>
>>> Jerry
>>>
>>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Session Persistence Problems
Posted by Jerry Malcolm <te...@malcolms.com>.
Thanks for the quick response, Luis. Answers below:
On 4/11/2019 3:22 AM, Luis Rodríguez Fernández wrote:
> Hello Jerry,
>
>> I'm using single sign-on
> Do you mean tomcat Single Sign On valve? [1], a third party solution or
> your custom implementation? That can change the game completely :)
Yes, standard Tomcat-provided single sign on valve
>
>> some RewriteRules in httpd
> Can you share them? That could change the game also :)
Here's some of my rewrite rules from httpd.conf for this virtualhost:
RewriteRule ^/create_user$
/idmanager/jsp/guest/createuser.jsp? [PT]
RewriteRule ^/forgot_password$
/idmanager/jsp/guest/forgotpassword.jsp? [PT]
RewriteRule ^/logoff$ /idmanager/jsp/guest/logoff.jsp [PT]
RewriteRule ^/change_password$
/idmanager/jsp/user/changepassword.jsp? [PT]
RewriteRule ^/login$ /idmanager/jsp/user/home.jsp [PT]
RewriteRule ^/userhome$ /idmanager/jsp/user/home.jsp? [PT]
RewriteRule ^/cart$ /order/jsp/guest/cart.jsp? [PT,QSA]
RewriteRule ^/checkout$ /order/jsp/guest/checkout.jsp? [PT]
RewriteRule ^/submitOrder$ /order/jsp/guest/orderSubmit.jsp?
[PT,QSA]
RewriteRule ^/displayImage$ /order/jsp/guest/productPage.jsp?
[PT,QSA]
RewriteRule ^/product$ /order/jsp/guest/productPage.jsp? [PT,QSA]
RewriteRule ^/storeFront$ /order/jsp/guest/storeFront.jsp [PT]
RewriteRule ^/orders$ /order/jsp/user/orderList.jsp? [PT]
RewriteRule ^/pay$ /payment/jsp/user/flcPayProvision.jsp [PT]
RewriteRule ^/projectlist$
/projectmanager/jsp/user/projectlist3.jsp? [PT]
RewriteRule ^/about$ /upartyrental/jsp/guest/about.jsp? [PT]
RewriteRule ^/$ /upartyrental/jsp/guest/uprHome.jsp [PT]
>
> Cheers,
>
> Luis
>
> [1]
> https://tomcat.apache.org/tomcat-9.0-doc/config/valve.html#Single_Sign_On_Valve
>
>
>
>
>
>
>
> El jue., 11 abr. 2019 a las 5:57, Jerry Malcolm (<te...@malcolms.com>)
> escribió:
>
>> I have a TC host that is running about 10 separate webapps that interact
>> with each other. I understand that sessions are per-webapp. But within
>> one webapp, with the same browser just making different calls to the
>> same webapp is starting new sessions about 30% of the time. I've put a
>> debug statement at the beginning of all of my JSPs that logs
>> session.isNew(). It'll start a new session, then use it for 10 or so
>> subsequent calls. But then it'll decide to drop that session and start a
>> new one that it'll subsequently use for a while. The setup is nothing
>> fancy. It's just calling several different JSPs within the same webapp
>> (context). I am keeping data in the session that really needs to
>> persist for the duration of the 'real' session between the user and the
>> site. So this is a serious problem. (This is happening both with
>> Firefox and Chrome). I'm using TC 9.0.1 on Windows.
>>
>> I definitely could have some misunderstandings here. But my first
>> understanding is that once a browser makes a call to a webapp, a session
>> is created, and that session remains around until invalidated on a
>> logout or a timeout occurred, and that webapp uses that session for the
>> remainder of the activity between that browser and that webapp. If
>> that's not the case, then please set me straight. If that assumption is
>> correct, what could possibly be causing the sessions to keep dropping
>> and new ones created?
>>
>> Interestingly, logon state is not being dropped with the new sessions.
>> I'm using single sign-on. So that may be ensuring the logon doesn't drop.
>>
>> The only thing I can come up with is that I'm using some RewriteRules in
>> httpd to map the complex url paths to single words like "/product". (SEO
>> advisor told me to do that...) I'm trying to see in the logs if there is
>> a correlation between rewrites and the new sessions. But I can't really
>> tell if that's what's causing it.
>>
>> Am I missing or do I have some sort of errant configuration setting that
>> is causing the sessions to keep reinitiating? Is there something else
>> I'm missing? I really need to have sessions that last as long as the
>> user is on the site.
>>
>> Suggestions? Help??
>>
>> Thx.
>>
>> 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
Re: Session Persistence Problems
Posted by Luis Rodríguez Fernández <uo...@gmail.com>.
Hello Jerry,
> I'm using single sign-on
Do you mean tomcat Single Sign On valve? [1], a third party solution or
your custom implementation? That can change the game completely :)
> some RewriteRules in httpd
Can you share them? That could change the game also :)
Cheers,
Luis
[1]
https://tomcat.apache.org/tomcat-9.0-doc/config/valve.html#Single_Sign_On_Valve
El jue., 11 abr. 2019 a las 5:57, Jerry Malcolm (<te...@malcolms.com>)
escribió:
> I have a TC host that is running about 10 separate webapps that interact
> with each other. I understand that sessions are per-webapp. But within
> one webapp, with the same browser just making different calls to the
> same webapp is starting new sessions about 30% of the time. I've put a
> debug statement at the beginning of all of my JSPs that logs
> session.isNew(). It'll start a new session, then use it for 10 or so
> subsequent calls. But then it'll decide to drop that session and start a
> new one that it'll subsequently use for a while. The setup is nothing
> fancy. It's just calling several different JSPs within the same webapp
> (context). I am keeping data in the session that really needs to
> persist for the duration of the 'real' session between the user and the
> site. So this is a serious problem. (This is happening both with
> Firefox and Chrome). I'm using TC 9.0.1 on Windows.
>
> I definitely could have some misunderstandings here. But my first
> understanding is that once a browser makes a call to a webapp, a session
> is created, and that session remains around until invalidated on a
> logout or a timeout occurred, and that webapp uses that session for the
> remainder of the activity between that browser and that webapp. If
> that's not the case, then please set me straight. If that assumption is
> correct, what could possibly be causing the sessions to keep dropping
> and new ones created?
>
> Interestingly, logon state is not being dropped with the new sessions.
> I'm using single sign-on. So that may be ensuring the logon doesn't drop.
>
> The only thing I can come up with is that I'm using some RewriteRules in
> httpd to map the complex url paths to single words like "/product". (SEO
> advisor told me to do that...) I'm trying to see in the logs if there is
> a correlation between rewrites and the new sessions. But I can't really
> tell if that's what's causing it.
>
> Am I missing or do I have some sort of errant configuration setting that
> is causing the sessions to keep reinitiating? Is there something else
> I'm missing? I really need to have sessions that last as long as the
> user is on the site.
>
> Suggestions? Help??
>
> Thx.
>
> Jerry
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
--
"Ever tried. Ever failed. No matter. Try Again. Fail again. Fail better."
- Samuel Beckett