The problem you have is that when someone clicks the backbutton, the user's browser renders the page from it's internal cache.  You can't control what happens when the user clicks the back button. 

The only thing you can do is disable caching on each page (via pragma no-cache, and other headers), but that can be unreliable because it's only a suggestion to the browser and behavior can vary from one browser to the next.  Further, if there are other caching mechanisms between the browser and the server, you still may not get what you want, and even if you did, you've eliminated one of the main browser performance features.

If anyone does know how to do this I'd love to know, but I don't there is a way.

Steve.

hello community,

I've faced the similar problem, and found following solution:

public class CacheControllPhaseListener implements PhaseListener
{
     public PhaseId getPhaseId()
     {
          return PhaseId.RENDER_RESPONSE;
     }

     public void afterPhase(PhaseEvent event)
     {
     }

     public void beforePhase(PhaseEvent event)
     {
          FacesContext facesContext = event.getFacesContext();
          HttpServletResponse response = (HttpServletResponse) facesContext
                    .getExternalContext().getResponse();
          response.addHeader("Pragma", "no-cache");
          response.addHeader("Cache-Control", "no-cache");
          response.addHeader("Cache-Control", "no-store");
          response.addHeader("Cache-Control", "must-revalidate");
          response.addHeader("Expires", "Mon, 8 Aug 2006 10:00:00 GMT");
     }
}

and in faces-config.xml

     <lifecycle>
         <phase-listener id="nocache">com.uniqa.session.CacheControllPhaseListener</phase-listener>
     </lifecycle>

hope this gives a good starting point.

Nevertheless - this works pretty fine for me.

Kind regards,
Ilya Dyoshin

Nagesh,

You can use the solution posted by Ilya. Even I'm using this in my application.

But in certain scenarios even this won't help. Like if you perform submit operation on a page and then postback to the same page without any redirect i.e showing page in response to POST request.

After post-back, move to any other page in your application and then press back button or just press refresh button on the page where from where you performed submit operation (initiated POST request).

Whenever POST request is resubmitted, browsers either show warning messages (like in IE and Chrome) or confirmation dialog boxes(like in Mozilla). In case the user press reload/refresh despite of these warning then duplicate submit is performed.

It is possible to get rid of these irritating messages and duplicate submits by using PRG (Post-Redirect-GET) design pattern.

After POST request, redirect to the same view-id from which the request is initiated. This way the response would be generated via Get request. Browsers don't ask for confirmation when GET request is resubmitted.

Here the catch is the data submitted in the POST request wouldn't be available after redirect if there is no page-load action is associated with that view-id.

To resolve this you can use Conversation scope as it keeps data even after redirect.

I have implemented the similar solution in my appliation and it's working perfectly as required on IE/Mozilla and Chrome.

The behavior is little different on Chrome because it caches 301 redirects. But it doesn't cause any problems so far.

I hope this will help you in your application.

Regards,
Gaurav Saini

P.S.: Please rate if this helps anyone.