inconsistency with session persistence

[Robert J. Carr]

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

[Robert J. Carr]

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

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

[Mark Thomas]

Post by Robert J. Carr
Actually, there's a small correction to my session persistence
description
https://tomcat.apache.org/tomcat-8.5-doc/config/manager.html#Special_Features

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 ...
* 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)

Post by Robert J. Carr
* 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

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

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

[Robert J. Carr]

Hi Mark-

Thanks for the response.

Post by Mark Thomas

Post by Robert J. Carr
* 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.

Post by Mark Thomas

Post by Robert J. Carr
* 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

[Mark Thomas]

Post by Mark Thomas

Post by Mark Thomas

Post by Robert J. Carr
* 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

Post by Mark Thomas
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
INFO [localhost-startStop-2]
contextDestroyed()

Not obviously relevant.

Post by Mark Thomas
On subsequent startup there are a lot more logs, but one warning that
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.

Post by Mark Thomas
INFO [localhost-startStop-1]
contextInitialized()

Not obviously relevant.

Post by Mark Thomas
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: users-***@tomcat.apache.org
For additional commands, e-mail: users-***@tomcat.apache.org

[Robert J. Carr]

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

[Mark Thomas]

Post by Robert J. Carr
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: users-***@tomcat.apache.org
For additional commands, e-mail: users-***@tomcat.apache.org