tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Detecting Expired Session via JavaScript?
Date Wed, 02 Dec 2015 15:55:58 GMT

On 12/1/15 2:39 PM, Jerry Malcolm wrote:
> On 12/1/2015 12:17 PM, Jose MarĂ­a Zaragoza wrote:
>> ts automatically resets the session timer.
>> Only if the request goes to the same application.
>> You can create a HttpSessionListener who saves some info on a shared
>> store when session is expired.
>> Anothe REST service could check the status of the session when is
>> requested by your page
> Jose,
> I understand the listener and storing the state in common storage. But
> I'm confused on your statement above about the same application.  I have
> several web apps running on the same host instance.  They all share a
> common login using SingleSignOn.

Each application has a distinct HttpSession object. The SingleSignOn
cookie allows each application to re-authenticate using the SSO
information, so you get a new HttpSession if your old one times out.

> If I hit any of the apps it resets the timer.

I don't think hitting app A will reset the session timeout of app B's
session. (Or maybe it does, but I didn't think that's how SSO worked in
Tomcat. Unfortunately, the SSO documentation[1] doesn't actually say
exactly how all this works.)

> Do they all have separate sessions but share a common login state?


> What is the relationship between "logged in" and separate webapp
> sessions that come and go independently. What I really care about is
> whether the authenticator is going to bounce the request to a login page
> or not.  It still seems like calling any app is going to reset the
> logged-in timer if I'm using single sign-on (?).

The authenticator is not going to sent you to a login page for any
application unless either of these events occurs:

(a) You explicitly log-out from one of the applications. This will
    terminate the SSO cookie and revoke your logins on all associated

(b) Your SSO cookie (or server-based info) expires. Then you will be
    asked to authenticate again.

If you are using SSO, this adds a bit of mystery to the situation, since
what you really want to find out is whether the /SSO token/ is still
valid. The validity of any of the various individual-application session
identifiers is irrelevant, since if the SSO token is valid, you will be
automatically re-authenticated to the individual applications.

I think you may have to re-think how you detect the expiration of your
users' logins.



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message