Handling HTTP Session timeout

[2devnull]

Do I need to write my own interceptor for HTTP session time out? How do I detect it transparently rather than in each controller and give the user a message that their session has time out?

[2devnull]

Is WebContentInterceptor getting used by the framework? I still would like to know how to let the user know that the session was timedout by giving a message.

[pburleson]

Take a look at the following class in J2EE:

javax.servlet.http.HttpSessionBindingListener

It's in at least J2EE 1.3, maybe earlier. The container will notify you when the session expires. (Or well, at least when it unbinds the values) This can be significantly longer than your defined session timeout. Depends on how your container handles it. There might be better ways, but that's how we're currently handling it.

Patrick

[thomasvdv]

Maybe you could use a Filter that stores a value in the Session object upon first request and then systematically verifies with each subsequent request if the value still exists within the user's session object. If the session timed out, the Filter will not find the value in the user's session object, and can then decide to redirect the user to a page with "a session timed out" message.

[2devnull]

That would not work since users are allowed to use the site without authenticating. Acegi already stores an object in the session, but if the user is authenticated and then the session timesout, I need to detect this, therefore I just can't check for a session object since they would get this message when using the site un-authenticated.

BTW - Since HTTP is stateless, how do you know which is the first request?

[oliverhutchison]

Instead of placing a special key in the session you could send a cookie to the user that stores the current session id and has a timeout that is some arbitrary length longer than the session timeout.

Then on each request you check to see if the session id you stored in the cookie matches the current session id. If not, then you can be sure that the session has timed out.

However what makes more sense in most web apps to define the set of pages that *must* have an established session and to place a filter around them that makes sure that this session exists.

Ollie

[2devnull]

But isn't the issue with Spring is that it always creates a session, therefore a session always exists? I think you point about the cookie makes sense, but since I am now depending on the user's browser settings, I must handle if they will accept this cookie also.[/quote]

[oliverhutchison]

since I am now depending on the user's browser settings, I must handle if they will accept this cookie also

Sorry I assumed that as you were using sessions you were also using cookies. Most people don't implement URL rewriting.

Anyway that's one of the resons why I suggested that my second option is a better choice

Ollie

[2devnull]

hmm.... interesting point, how does Spring handle if the user will now accept the session cookie? does the framework switch to URL re-writing with the JSESSIONID as a request parameter? hence my earlier question about the useage of the WebContentInterceptor.

[oliverhutchison]

does the framework switch to URL re-writing with the JSESSIONID as a request parameter? hence my earlier question about the useage of the WebContentInterceptor.

It should make no difference to Spring whether sessions are cookie or URL based and there is no standard way to enable or disable URL re-writing.

If you want to use URL re-writing then it is your responsibility to make sure that *every* link in you site is passed through a processor that will re-write it. Have a look at this link for a short description of what you need to do http://www-306.ibm.com/software/webs...401010102.html

Ollie