Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.2.15-core , 2.0.0-core
    • Component/s: None
    • Labels:
      None

      Description

      provide solution to handle session timeouts

        Activity

        Hide
        Matthias Weßendorf added a comment -

        providing a (optional?) TimoutConfigurator might help

        Show
        Matthias Weßendorf added a comment - providing a (optional?) TimoutConfigurator might help
        Hide
        Matthias Weßendorf added a comment -

        Why not introducing a new ctx param:

        <context-param>
        <param-name>org.apache.myfaces.trinidad.TIMEOUT_URL</param-name>
        <param-value>my_page_url</param-value>
        </context-param>

        and incase of PPR AND!!! TIMEOUT_URL is set, send down something like this:
        <?Tr-XHR-Response-Type ?>
        <redirect>
        TIMEOUT_URL
        </redirect>
        (TrPage._handlePprResponse() already handles <redirect>url</redirect>)

        when no TIMEOUT_URL is set, I see two options:
        -redirect to "/"
        -<script>alert("timeout");</script> (yes, timeout is NOT hard-coded....)

        For the non PPR

        externalContext.redirect(TIMEOUT_URL);
        (or "/")

        Please note, (being a portlet ignorant ) I don't know if/how this
        works in a portlet.

        Show
        Matthias Weßendorf added a comment - Why not introducing a new ctx param: <context-param> <param-name>org.apache.myfaces.trinidad.TIMEOUT_URL</param-name> <param-value>my_page_url</param-value> </context-param> and incase of PPR AND!!! TIMEOUT_URL is set, send down something like this: <?Tr-XHR-Response-Type ?> <redirect> TIMEOUT_URL </redirect> (TrPage._handlePprResponse() already handles <redirect>url</redirect>) when no TIMEOUT_URL is set, I see two options: -redirect to "/" -<script>alert("timeout");</script> (yes, timeout is NOT hard-coded....) For the non PPR externalContext.redirect(TIMEOUT_URL); (or "/") Please note, (being a portlet ignorant ) I don't know if/how this works in a portlet.
        Hide
        Scott O'Bryan added a comment -

        I thought trinidad already had a usecase for this. In either case, yes, a configurator would be the right way to handle this although, in a portlet environment, session timeouts are largely irrelevant. The portlet handles the request and if the portlet's session has timed out, our portlet may not even get the request. For the full page case, this would be fine. For the PPR case, it may hose us.

        In any case, what I would do in the portal case is, if we do get the request, I would either treat it like we have not timeout_url OR I would simply write out the redirect url to be the current action url. This will "try" to post an action request to the portlet, but then the portal will take over and prompt the user for sign in.

        I have some code for a configuator which does something similar that I can forward you.

        Scott

        Show
        Scott O'Bryan added a comment - I thought trinidad already had a usecase for this. In either case, yes, a configurator would be the right way to handle this although, in a portlet environment, session timeouts are largely irrelevant. The portlet handles the request and if the portlet's session has timed out, our portlet may not even get the request. For the full page case, this would be fine. For the PPR case, it may hose us. In any case, what I would do in the portal case is, if we do get the request, I would either treat it like we have not timeout_url OR I would simply write out the redirect url to be the current action url. This will "try" to post an action request to the portlet, but then the portal will take over and prompt the user for sign in. I have some code for a configuator which does something similar that I can forward you. Scott
        Hide
        Richard Yee added a comment -

        I have tried to handle timeouts with a servlet filter however, if a PPR request happens after a session timeout, the servlet filter cannot handle the request such that the entire page is replaced with the session timeout page. The JavaScript code that is doing the PPR ignores the response from the servlet filter which is either a redirect or a forward to a session expiration JSP page. I suppose having Trinidad handle the session timeout through a centralized mechanism is the way to go here.

        Show
        Richard Yee added a comment - I have tried to handle timeouts with a servlet filter however, if a PPR request happens after a session timeout, the servlet filter cannot handle the request such that the entire page is replaced with the session timeout page. The JavaScript code that is doing the PPR ignores the response from the servlet filter which is either a redirect or a forward to a session expiration JSP page. I suppose having Trinidad handle the session timeout through a centralized mechanism is the way to go here.
        Hide
        Mathias Walter added a comment -

        How is the progress of this bug? I run into the same problem.
        After a session timeout, no PPR link is working anymore. There is no error message.

        A user would expect to get at least an error message. I'd like to redirect to the login page.

        Here is the exception message:

        SCHWERWIEGEND: JSF1054: (Phase ID: RESTORE_VIEW 1, View ID: ) Exception thrown during phase execution: javax.faces.event.PhaseEvent[source=com.sun.faces.lifecycle.LifecycleImpl@64f6fe]
        21.07.2008 13:38:20 org.apache.myfaces.trinidadinternal.config.xmlHttp.XmlHttpConfigurator handleError
        SCHWERWIEGEND: Server Exception during PPR, #1
        javax.servlet.ServletException: viewId:/general/Patient.jsf - View /general/Patient.jsf could not be restored.
        at javax.faces.webapp.FacesServlet.service(FacesServlet.java:270)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._invokeDoFilter(TrinidadFilterImpl.java:238)
        at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._doFilterImpl(TrinidadFilterImpl.java:195)
        at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl.doFilter(TrinidadFilterImpl.java:138)
        at org.apache.myfaces.trinidad.webapp.TrinidadFilter.doFilter(TrinidadFilter.java:92)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83)
        at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:58)
        at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
        at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:85)
        at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
        at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
        at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
        at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
        at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
        at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:73)
        at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
        at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:433)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:263)
        at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
        at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:584)
        at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
        at java.lang.Thread.run(Thread.java:619)
        Caused by: javax.faces.application.ViewExpiredException: viewId:/general/Patient.jsf - View /general/Patient.jsf could not be restored.
        at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:186)
        at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:100)
        at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:104)
        at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
        at javax.faces.webapp.FacesServlet.service(FacesServlet.java:265)
        ... 32 more

        Show
        Mathias Walter added a comment - How is the progress of this bug? I run into the same problem. After a session timeout, no PPR link is working anymore. There is no error message. A user would expect to get at least an error message. I'd like to redirect to the login page. Here is the exception message: SCHWERWIEGEND: JSF1054: (Phase ID: RESTORE_VIEW 1, View ID: ) Exception thrown during phase execution: javax.faces.event.PhaseEvent [source=com.sun.faces.lifecycle.LifecycleImpl@64f6fe] 21.07.2008 13:38:20 org.apache.myfaces.trinidadinternal.config.xmlHttp.XmlHttpConfigurator handleError SCHWERWIEGEND: Server Exception during PPR, #1 javax.servlet.ServletException: viewId:/general/Patient.jsf - View /general/Patient.jsf could not be restored. at javax.faces.webapp.FacesServlet.service(FacesServlet.java:270) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._invokeDoFilter(TrinidadFilterImpl.java:238) at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._doFilterImpl(TrinidadFilterImpl.java:195) at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl.doFilter(TrinidadFilterImpl.java:138) at org.apache.myfaces.trinidad.webapp.TrinidadFilter.doFilter(TrinidadFilter.java:92) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83) at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:58) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:85) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:73) at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:433) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:263) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:584) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:619) Caused by: javax.faces.application.ViewExpiredException: viewId:/general/Patient.jsf - View /general/Patient.jsf could not be restored. at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:186) at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:100) at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:104) at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:265) ... 32 more
        Hide
        Mathias Walter added a comment -

        And by the way: IMHO it's a blocking bug and not a new feature.
        Matthias, please change the priority and type of issue.

        Show
        Mathias Walter added a comment - And by the way: IMHO it's a blocking bug and not a new feature. Matthias, please change the priority and type of issue.
        Hide
        Matthias Weßendorf added a comment -

        made it a critical bug

        Show
        Matthias Weßendorf added a comment - made it a critical bug
        Hide
        Matthias Weßendorf added a comment -

        added getRequestedSessionId() and isRequestedSessionIdValid() to ExternalContextUtils, since JSF 1.x API is to poor for that.
        These funcs will be used in the configurator, to handle the redirect on timeout.

        Show
        Matthias Weßendorf added a comment - added getRequestedSessionId() and isRequestedSessionIdValid() to ExternalContextUtils, since JSF 1.x API is to poor for that. These funcs will be used in the configurator, to handle the redirect on timeout.
        Hide
        Mathias Walter added a comment -

        Still no progress an this critical bug.

        There is a discussion at the user mailing list: http://www.mail-archive.com/users@myfaces.apache.org/msg53574.html

        But how to implement this PPR hook? Based on the discussion, a fix should be easy to implement.

        Show
        Mathias Walter added a comment - Still no progress an this critical bug. There is a discussion at the user mailing list: http://www.mail-archive.com/users@myfaces.apache.org/msg53574.html But how to implement this PPR hook? Based on the discussion, a fix should be easy to implement.
        Hide
        Scott O'Bryan added a comment -

        Actually, a change was committed, the bug was just never closed. Closing now. Finally.

        Show
        Scott O'Bryan added a comment - Actually, a change was committed, the bug was just never closed. Closing now. Finally.

          People

          • Assignee:
            Matthias Weßendorf
            Reporter:
            Matthias Weßendorf
          • Votes:
            8 Vote for this issue
            Watchers:
            9 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development