inconsistency with session persistence

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

inconsistency with session persistence

Robert J. Carr-2
I've read around the docs and various help sites trying to figure this out,
by my situation isn't matching anything I've read, so looking for a little
extra help.

Here's my config: [tomcat 8.5.24 | java 8.0 | macos 10.14]

According to here:
https://tomcat.apache.org/tomcat-8.5-doc/config/manager.html#Special_Features

It says a session should normally persist if the application is reloaded or
the server restarted, however, that is not the behavior I'm experiencing.
Here's what happens:

When a user logs in I create a session and store in it a single custom
object that I’ve marked serializable, and all of its members are
serializable (just Strings and an Instant).

When the application restarts both the session and the contents seem to be
restored as expected.  But if the application is undeployed and redeployed
the session seems to get recreated automatically, with a new session id
(and negotiated through cookies with the client), but the contents of the
session are now gone.

To explain a bit differently, I have a test page that allows access only to
an authenticated user.  This test page will spit out both the session id
and the contents of the session object.

If I login normally and go to this page everything is fine.  If I reload my
application and then reload this page then everything stays the same as
expected, and I'm sure this page isn't being cached (my verification has to
do with the Instant I mentioned earlier).

But if I undeploy and redeploy the application, or restart the server, then
I can still reload this protected page without having to login, but two
things are different:

 1) there's a new session id
 2) the session contents are now unavailable

By hooking up a session listener I can confirm that a new session is being
silently created, although the session is never getting destroyed.

So what's going on here?  This doesn't seem to be what the docs describe.
This scenario is causing problems because the session data I store includes
authentication info for an external resource, so my users are effectively
only 1/2 logged in, and in a weird state.

Two more small details:

 * The doc I referenced talks about Persistent Managers, but I'm not using
anything non-standard.

 * The one non-standard thing I am using is the single-sign-on valve, but
this was only to overcome a different (reported) bug I found dealing with
programmatic logins (long story).

Thanks for any help!

Robert
Reply | Threaded
Open this post in threaded view
|

Re: inconsistency with session persistence

Robert J. Carr-2
Actually, there's a small correction to my session persistence description
from before.   From the doc I referenced here:


https://tomcat.apache.org/tomcat-8.5-doc/config/manager.html#Special_Features

It says:

> Whenever Apache Tomcat is shut down normally and restarted, or when an
application reload is triggered, the ... All such saved sessions will then
be deserialized and activated ...

But here's what I'm finding:

 * if the application is restarted then the session and its contents are
maintained as expected

 * if the application is undeployed and redeployed (while the server
remains running) a new session is silently generated, and any contents
disappear, but the user maintains her authentication

 * if the server is shut down and restarted then everything seems to
disappear, as I then get a 403 when trying to access the protected page

Again, this isn't consistent with the documentation, so not sure what I'm
doing wrong.

Thanks-
Robert
Reply | Threaded
Open this post in threaded view
|

Re: inconsistency with session persistence

markt
On October 23, 2018 9:19:50 PM UTC, "Robert J. Carr" <[hidden email]> wrote:

>Actually, there's a small correction to my session persistence
>description
>from before.   From the doc I referenced here:
>
>
>https://tomcat.apache.org/tomcat-8.5-doc/config/manager.html#Special_Features
>
>It says:
>
>> Whenever Apache Tomcat is shut down normally and restarted, or when
>an
>application reload is triggered, the ... All such saved sessions will
>then
>be deserialized and activated ...
>
>But here's what I'm finding:
>
>* if the application is restarted then the session and its contents are
>maintained as expected
>
> * if the application is undeployed and redeployed (while the server
>remains running) a new session is silently generated, and any contents
>disappear, but the user maintains her authentication

As expected. Redeploy (undeploy+deploy)  != reload (stop+start)

>
> * if the server is shut down and restarted then everything seems to
>disappear, as I then get a 403 when trying to access the protected page

Expected behaviour here will depend on whether a server shutdown shuts down Tomcat cleanly. From your description it sounds like it does not.

Mark

>Again, this isn't consistent with the documentation, so not sure what
>I'm
>doing wrong.
>
>Thanks-
>Robert


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: inconsistency with session persistence

Robert J. Carr-2
Hi Mark-

Thanks for the response.

> > * if the application is undeployed and redeployed (while the server
> >remains running) a new session is silently generated, and any contents
> >disappear, but the user maintains her authentication
>
> As expected. Redeploy (undeploy+deploy)  != reload (stop+start)

This is a good point and why I sent the follow-up email.  However, I'd
expect the undeploy+deploy to be the one to completely clean out and
invalidate the session, but the distinction isn't important for my
situation.

> > * if the server is shut down and restarted then everything seems to
> >disappear, as I then get a 403 when trying to access the protected page
>
> Expected behaviour here will depend on whether a server shutdown shuts
down Tomcat cleanly. From your description it sounds like it does not.

I just re-ran my test getting the same result, i.e., after a server restart
a previously accessible request now gives a 403.  Looking at the logs, the
shutdown seems fine (i.e., nothing above INFO), and there were only a few
lines, but this one might be relevant:

INFO [localhost-startStop-2]
org.apache.catalina.core.ApplicationContext.log SessionListener:
contextDestroyed()

On subsequent startup there are a lot more logs, but one warning that
doesn't seem relevant:

WARNING [main] org.apache.tomcat.util.digester.SetPropertiesRule.begin
[SetPropertiesRule]{Server/Service/Engine/Realm/Realm/CredentialHandler}
Setting property 'keyLength' to '256' did not find a matching property.

But maybe it is?  There was also this session relevant line:

INFO [localhost-startStop-1]
org.apache.catalina.core.ApplicationContext.log SessionListener:
contextInitialized()

So not sure what is going on.  I'll see if I can figure out if that WARNING
is causing issues.  Thanks for the guidance, but please let me know if
there's anything else I can look at.

Robert
Reply | Threaded
Open this post in threaded view
|

Re: inconsistency with session persistence

markt
On October 24, 2018 3:50:59 PM UTC, "Robert J. Carr" <[hidden email]> wrote:

>> > * if the server is shut down and restarted then everything seems to
>> >disappear, as I then get a 403 when trying to access the protected
>page
>>
>> Expected behaviour here will depend on whether a server shutdown
>shuts
>down Tomcat cleanly. From your description it sounds like it does not.
>
>I just re-ran my test getting the same result, i.e., after a server
>restart
>a previously accessible request now gives a 403.  Looking at the logs,
>the
>shutdown seems fine (i.e., nothing above INFO), and there were only a
>few
>lines, but this one might be relevant:
>
>INFO [localhost-startStop-2]
>org.apache.catalina.core.ApplicationContext.log SessionListener:
>contextDestroyed()

Not obviously relevant.

>On subsequent startup there are a lot more logs, but one warning that
>doesn't seem relevant:
>
>WARNING [main] org.apache.tomcat.util.digester.SetPropertiesRule.begin
>[SetPropertiesRule]{Server/Service/Engine/Realm/Realm/CredentialHandler}
>Setting property 'keyLength' to '256' did not find a matching property.
>
>But maybe it is?  

Something isn't right in the config but I don't think it will affect this.

> There was also this session relevant line:
>
>INFO [localhost-startStop-1]
>org.apache.catalina.core.ApplicationContext.log SessionListener:
>contextInitialized()

Not obviously relevant.

>So not sure what is going on.  I'll see if I can figure out if that
>WARNING
>is causing issues.  Thanks for the guidance, but please let me know if
>there's anything else I can look at.

Take a look at the raw http. That might give you some clues particularly with session  values.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: inconsistency with session persistence

Robert J. Carr-2
Hi Mark-

Thanks again for the response.

I fixed the credential handler config, it just had a superfluous attribute,
so the WARNING went away and as you predicted didn't change the session
outcome.  Now when stopping and starting tomcat I'm not seeing any log
higher than an INFO, it is appears to be doing this cleanly, but my problem
persists.

I'll take a look at the http to see what is going on with the session
tokens and cookies, thanks for the advice.  However, it's still strange to
me that it works for an app restart, meaning from the application
perspective it is correctly implemented, e.g., with respect to
serialization, but not a server restart, although the docs indicate these
should work the same.

I know sessions are intertwined with single sign-on.  Are we sure this
isn't the problem?  As I said, I need to turn on single sign-on to fix
another login bug, but I might be able to turn it off if it'd help in
diagnosing this problem.

Thanks-
Robert
Reply | Threaded
Open this post in threaded view
|

Re: inconsistency with session persistence

markt
On 24/10/2018 19:01, Robert J. Carr wrote:

> Hi Mark-
>
> Thanks again for the response.
>
> I fixed the credential handler config, it just had a superfluous attribute,
> so the WARNING went away and as you predicted didn't change the session
> outcome.  Now when stopping and starting tomcat I'm not seeing any log
> higher than an INFO, it is appears to be doing this cleanly, but my problem
> persists.
>
> I'll take a look at the http to see what is going on with the session
> tokens and cookies, thanks for the advice.  However, it's still strange to
> me that it works for an app restart, meaning from the application
> perspective it is correctly implemented, e.g., with respect to
> serialization, but not a server restart, although the docs indicate these
> should work the same.
>
> I know sessions are intertwined with single sign-on.  Are we sure this
> isn't the problem?  As I said, I need to turn on single sign-on to fix
> another login bug, but I might be able to turn it off if it'd help in
> diagnosing this problem.

When you say restart the server do you mean you stop/start Tomcat or
reboot the server?

SSO may be playing a role. Are you using Tomcat's SSO or something else?

Generally, Tomcat persists session. Optionally (enabled by default)
Tomcat caches the authenticated user ID in the session. So if the
session is cached, the user should remain authenticated.

The authentication mechanism also plays a part as browsers will resend
credentials on subsequent requests if BASIC auth is used.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]