Share 'Session-Timeout' Logic

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

dswenson

I've recently adjusted the Share session-timeout in the Share web.xml for a client. The client would like a message (similar to the one given on login failure via the "?error=true" doLogin argument) to appear when the user is redirected to the login page after exceeding the configured inactivity timeout.

I've been looking around in the Share code but I can't seem to find the code where the session-timeout is used for redirecting to the login page. Could anyone point me in the right direction as to where that logic is contained?

Thank you.

afaust

Hello,

there is no such code specific to the session timeout. When the session timeout is reached, the web application server will simply have "forgotten" who the user is, e.g. any authentication data contained in the session is lost. The next time the user navigates to a page, this will be noticed by the Surf framework and the user will be redirected to the login page as any unauthenticated user would.

There is no way to determine reliably if the user is redirected to the login page because of a timed-out session. Sure, the client will likely submit a session cookie, but this could also be faked or be a session cookie from the last time the user accessed the page months ago.

There are various places where an authentication check is performed and a redirect to the login page or an error might occur. The primary redirect to login-page is handled in the class org.springframework.extensions.surf.mvc.PageView, but any authentication error in any Share web script (or even client-side triggered AJAX requests) might also redirect to the root context of the Share web application with the cookie already gone. I.e. if an AJAX call fails due to session timeout, the client-side handling of the response will reload the page and this reload should already be lackig the now obsolete session cookie, preventing you from identifying this reload as a "session has timed out" case.

Regards
Axel