Announcement Announcement Module
Collapse
No announcement yet.
Session expiry Page Title Module
Move Remove Collapse
This topic is closed
X
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Session expiry

    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

  • #2
    Session timeout handling

    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

    Comment


    • #3
      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.

      Comment


      • #4
        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

        Comment


        • #5
          Would you mind posting the rest of that stacktrace?

          Comment


          • #6
            sure:

            Code:
            [#|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

            Comment


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

              Comment


              • #8
                Originally posted by 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
                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?

                Comment


                • #9
                  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.

                  Comment


                  • #10
                    Hi,

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

                    Cheers

                    Rakesh

                    Comment


                    • #11
                      I would NOT recommend setting infinite HttpSession times in web.xml. You'll just use up most of your server memory.
                      If every user of my app needs to be logged in I would need a session per user anyway so I don't see how its going to use more memory?

                      The only issue i can see is if the user doesn't return to the app (and never logged off). In that case, there is an argument that the session will remain indefinately.

                      Perhaps a combination might be better? A session timeout of double the time you want (60 mins) and a servlet filter for the actual timeout you want (30 mins).

                      If the user returns to the app after 30 mins but before 60, your servelt filter will catch that (and invalidate the session).

                      If the user never comes back or comes back after 60 mins, the web container will invalidate the sesion for you conserving memory.

                      Cheers

                      R

                      Comment


                      • #12
                        Hi,

                        just a quick update - i have upgraded to acegi-security-1.0.0-RC2.jar

                        and i still get the same stack trace once the server session has expired.

                        I think i need to do manual session control using filters.

                        Any thoughts?

                        Cheers

                        R

                        Comment

                        Working...
                        X