Session expiry

[too_many_details]

Hi,

I have configured session expiry for my app in web.xml to 30 minutes.

However, after 30 minutes, clicking on any link in the app produces a rather ugly stack trace:

java.lang.IllegalStateException: Cannot create a session after the response has been committed
org.apache.coyote.tomcat5.CoyoteRequest.doGetSessi on(CoyoteRequest.java:2356)
org.apache.coyote.tomcat5.CoyoteRequest.getSession (CoyoteRequest.java:2202)
...

Is there some way I can get Acegi to handle timeout a bit more gracefully? In previous proejcts I set expiry in web.xml to be infinite and used a servlet filter to check a timestamp in the session to decide whether the user been away too long. I'm hoping Acegi has something 'out-of-the-box' for this.

Cheers

rakesh

[ta796]

I have a similar need for session timeout handling.

As far as my understanding is concerned ACEGi will go the login page(loginFormUrl property of authenticationProcessingFilterEntryPoint) if the session has timed out OR if a user accesses ACEGI secured site for the first time(i.e is not yet logged in).

How can I distinguish between the 2 situations ? I need to let the user know (via a message on the login page)for the case where their session has timed out.

Thanks in advance

[ta796]

With some thinking, I want to know, is there a way that I can test some value on the ACEGI loginForm login.jsp page which can distinguish this situation for me and display the appropriate message.

[too_many_details]

I suspect, and please tell me if i'm wrong, that the way to go is with a servlet filter.

Set the session expiry to -1 in web.xml and then have the servelt filter put a date object in the session. Each url request will update this date. If the difference between now and the date in the session is greater than 30 mins then invalidate the session, clear the acegi context and go to the logon page.

Hopefully that should work?

Cheers

Rakesh

[RayKrueger]

Would you mind posting the rest of that stacktrace?

[too_many_details]

sure:

[#|2006-04-18T12:58:17.608+0100|SEVERE|sun-appserver-ee8.1|javax.enterprise.system.container.web|_ThreadID=21;|StandardWrapperValve[cupid]: Servlet.service() for servlet cupid threw exception
java.lang.IllegalStateException: Cannot create a session after the response has been committed
	at org.apache.coyote.tomcat5.CoyoteRequest.doGetSession(CoyoteRequest.java:2356)
	at org.apache.coyote.tomcat5.CoyoteRequest.getSession(CoyoteRequest.java:2202)
	at org.apache.coyote.tomcat5.CoyoteRequestFacade.getSession(CoyoteRequestFacade.java:838)
	at org.acegisecurity.ui.WebAuthenticationDetails.<init>(WebAuthenticationDetails.java:55)
	at org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.createAuthentication(AnonymousProcessingFilter.java:99)
	at org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:140)
	at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:303)
	at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:246)
	at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:303)
	at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:220)
	at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:303)
	at org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:173)
	at org.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:120)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:210)
	at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:55)
	at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:161)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:263)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:551)
	at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:225)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:173)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:551)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:170)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:551)
	at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:933)
	at com.sun.enterprise.web.connector.httpservice.HttpServiceProcessor.process(HttpServiceProcessor.java:226)
	at com.sun.enterprise.web.HttpServiceWebContainer.service(HttpServiceWebContainer.java:2074)

Rakesh

[Luke Taylor]

This shouldn't happen with the latest codebase because WebAuthenticationDetails no longer forces session creation.

[jglynn]

I suspect, and please tell me if i'm wrong, that the way to go is with a servlet filter.

Set the session expiry to -1 in web.xml and then have the servelt filter put a date object in the session. Each url request will update this date. If the difference between now and the date in the session is greater than 30 mins then invalidate the session, clear the acegi context and go to the logon page.

Hopefully that should work?

Cheers

Rakesh

I'm stuck trying to solve the same issue as user ta796.
I'm not sure this solution is the best way to achieve this.
Does anyone have any other ideas for how to go about this?

[Ben Alex]

I would NOT recommend setting infinite HttpSession times in web.xml. You'll just use up most of your server memory.

It's probably better to have a cookie sent to the user upon successful authentication, a bit like the remember-me services do. Then, in your "authentication login page", check if that cookie exists. If it does, you can let the user know they logged in before, but their session timed out. Your "logout" use case would of course clear the cookie.

As Luke mentioned, the underlying cuase of the exception has been corrected in CVS. However, it's still important to use the HttpSession semantics properly.

[too_many_details]

Hi,

any example code thats shows the cookie setting in action? Is it not in Acegi already?

Cheers

Rakesh