ADF Faces : session timeout best practice

Question

hi
I made these small modifications to the web.xml file in the SRDemoSample application:
(a) I changed the login-config from this ...
  <login-config>
    <auth-method>FORM</auth-method>
    <form-login-config>
      <form-login-page>infrastructure/SRLogin.jspx</form-login-page>
      <form-error-page>infrastructure/SRLogin.jspx</form-error-page>
    </form-login-config>
  </login-config>... to this
  <login-config>
    <auth-method>BASIC</auth-method>
  </login-config>(b) I changed the session-timeout to 1 minute.
  <session-config>
    <session-timeout>1</session-timeout>
  </session-config>Please consider this scenario:
(1) Run the UserInterface project of the SRDemoSample application in JDeveloper.
(2) Authenticate using "sking" and password "welcome".
(3) Click on the "My Service Requests" tab.
(4) Click on a "Request Id" like "111". You should see a detail page titled "Service Request Information for SR # 111" that shows detail data on the service request.
(5) Wait for at least one minute for the session to timeout.
(6) Click on the "My Service Requests" tab again. I see the same detail page as in (4), now titled "Service Request Information for SR #" and not showing any detail data.
question
What is the best practice to detect such session timeouts and handle them in a user friendly way in an ADF Faces application?
thanks
Jan Vervecken

Answer 1

Hi,
no. Here's the content copied from a word doc:
A frequent question on the JDeveloper OTN forum, and also one that has been asked by customers directly, is how to detect and graceful handle user session expiry due to user inactivity.
The problem of user inactivity is that there is no way in JavaEE for the server to call the client when the session has expired. Though you could use JavaScript on the client display to count
down the session timeout, eventually showing an alert or redirecting the browser, this goes with a lot of overhead. The main concern raised against unhandled session invalidation due to user
inactivity is that the next user request leads to unpredictable results and errors messages. Because all information stored in the user session get lost upon session expiry, you can't recover the
session and need to start over again. The solution to this problem is a servlet filter that works on top of the Faces servlet. The web.xml file would have the servlet configured as follows
1.     <filter>
2.         <filter-name>ApplicationSessionExpiryFilter</filter-name>
3.         <filter-class>
4.             adf.sample.ApplicationSessionExpiryFilter
5.         </filter-class>
6.         <init-param>
7.             <param-name>SessionTimeoutRedirect</param-name>
8.             <param-value>SessionHasExpired.jspx</param-value>
9.         </init-param>
10.     </filter>
This configures the "ApplicationSessionExpiryFilter" servlet with an initialization parameter for the administrator to configure the page that the filter redirects the request to. In this
example, the page is a simple JSP page that only prints a message so the user knows what has happened. Further in the web.xml file, the filter is assigned to the JavaServer Faces
servlet as follows
1.     <filter-mapping>
2.             <filter-name>ApplicationSessionExpiryFilter</filter-name>
3.             <servlet-name>Faces Servlet</servlet-name>
4.         </filter-mapping>
The Servlet filter code compares the session Id of the request with the current session Id. This nicely handles the issue of the JavaEE container implicitly creating a new user session for the incoming request.
The only special case to be handled is where the incoming request doesn't have an associated session ID. This is the case for the initial application request.
1.     package adf.sample;
2.     
3.     import java.io.IOException;
4.     
5.     import javax.servlet.Filter;
6.     import javax.servlet.FilterChain;
7.     import javax.servlet.FilterConfig;
8.     import javax.servlet.ServletException;
9.     import javax.servlet.ServletRequest;
10.     import javax.servlet.ServletResponse;
11.     import javax.servlet.http.HttpServletRequest;
12.     import javax.servlet.http.HttpServletResponse;
13.     
14.     
15.     public class ApplicationSessionExpiryFilter implements Filter {
16.         private FilterConfig _filterConfig = null;
17.        
18.         public void init(FilterConfig filterConfig) throws ServletException {
19.             _filterConfig = filterConfig;
20.         }
21.     
22.         public void destroy() {
23.             _filterConfig = null;
24.         }
25.     
26.         public void doFilter(ServletRequest request, ServletResponse response,
27.                              FilterChain chain) throws IOException, ServletException {
28.     
29.     
30.             String requestedSession =   ((HttpServletRequest)request).getRequestedSessionId();
31.             String currentWebSession =  ((HttpServletRequest)request).getSession().getId();
32.            
33.             boolean sessionOk = currentWebSession.equalsIgnoreCase(requestedSession);
34.           
35.             // if the requested session is null then this is the first application
36.             // request and "false" is acceptable
37.            
38.             if (!sessionOk && requestedSession != null){
39.                 // the session has expired or renewed. Redirect request
40.                 ((HttpServletResponse) response).sendRedirect(_filterConfig.getInitParameter("SessionTimeoutRedirect"));
41.             }
42.             else{
43.                 chain.doFilter(request, response);
44.             }
45.         }
46.        
47.     }
This servlet filter works pretty well, except for sessions that are expired because of active session invalidation e.g. when nuking the session to log out of container managed authentication. In this case my
recommendation is to extend line 39 to also include a check if security is required. This can be through another initialization parameter that holds the name of a page that the request is redirected to upon logout.
In this case you don't redirect the request to the error page but continue with a newly created session.
Ps.: For testing and development, set the following parameter in web.xml to 1 so you don't have to wait 35 minutes
1.     <session-config>
2.         <session-timeout>1</session-timeout>
3.     </session-config> Frank
Edited by: Frank Nimphius on Jun 9, 2011 8:19 AM