browser back + viewscope beans

Question

What the problem is : What happens when clicking on the browser back button --> opens up a page whose viewscoped-managedbean is already destroyed --> submit

Answer 1

The disadvantage of disabling the browser cache of a page is that the user will see an browsers error page if he use browser back to navigate to previous page. So another solutions is to identify if the page comes from the server or from the browser cache using javascript:

First create a simple backing bean which serves a unique id (in my case current system time):

@Named("browserCacheController")
@RequestScoped
public class BrowserCacheController implements Serializable {
private static final long serialVersionUID = 1L;
/**
 * Returns a unique increasing id for each request
 * @return
 */
public long getCacheID() {
    return System.currentTimeMillis();
}   
}

So now you can test if a page is served from the server or browser and redirecting the user if the current page comes from browser cache. See the following javascript code placed into a jsf page which should not be cached by browser:

<script type="text/javascript">
    // check for latestCacheID
    if (!isValidCacheID(#{browserCacheController.cacheID})) {
        //redirect to some page
        document.location="#{facesContext.externalContext.requestContextPath}/index.jsf";
    }

    // test cacheID if it comes from the server....
    function isValidCacheID(currentCacheID) {
        if (!('localStorage' in window && window['localStorage'] !== null))
            return true; // old browsers not supported
        var latestCacheID=localStorage.getItem("org.imixs.latestCacheID");
        if (latestCacheID!=null && currentCacheID<=latestCacheID) {
            return false; // this was a cached browser page!
        }
        // set new id
        localStorage.setItem("org.imixs.latestCacheID", currentCacheID);
        return true;
    }
</script>

The script can also be placed into facelet to make the jsf code more clean.

Answer 2

The browser seems to have served the page from its cache instead of sending a fullworthy HTTP GET request to the server, while you have JSF state saving method set to server (which is the default).

There are 2 ways to solve this problem:

1. Tell the browser to not cache the dynamic JSF pages. You can do this with help of a filter.

   @Override
   public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
       HttpServletRequest req = (HttpServletRequest) request;
       HttpServletResponse res = (HttpServletResponse) response;
   
       if (!req.getRequestURI().startsWith(req.getContextPath() + ResourceHandler.RESOURCE_IDENTIFIER)) { // Skip JSF resources (CSS/JS/Images/etc)
           res.setHeader("Cache-Control", "no-cache, no-store, must-revalidate"); // HTTP 1.1.
           res.setHeader("Pragma", "no-cache"); // HTTP 1.0.
           res.setDateHeader("Expires", 0); // Proxies.
       }
   
       chain.doFilter(request, response);
   }
   

   Map the filter on the FacesServlet or its same URL-pattern.

2. Set the JSF state saving method to client, so that the entire view state is stored in a hidden field of the form instead of in the session in the server side.

   <context-param>
       <param-name>javax.faces.STATE_SAVING_METHOD</param-name>
       <param-value>client</param-value>
   </context-param>
   

The filter way is preferable.