views:

368

answers:

2

Basically all pages on this site I am building cannot be accessed when the user clicks on "Back" (or with key control) in the browser, and the page should expire if one is trying to navigate back in history.

I put into Global.asax::Application_BeginRequest

    Response.Cache.SetCacheability(HttpCacheability.NoCache)
    Response.Cache.SetExpires(DateTime.UtcNow.AddDays(-1))
    Response.Cache.SetValidUntilExpires(False)
    Response.Cache.SetRevalidation(HttpCacheRevalidation.AllCaches)
    Response.Cache.SetNoStore()

This would clear out the cache and disallow going back to any pages when the user is logged out, but doesn't do the job while the user is logged in.

I saw posts where people suggested using a javascript approach, by calling

    History.Forward(1)

on the page. But I wouldn't like to do this, as it will require javascript enabled to work (which user can disable).

Appreciate any suggestions.

+2  A: 

The only way you can consistently do this is if you are using https. If not you have no way to enforce the browser to not use a cached page. There are the hacks you mentioned about but they are not full proof. If it is really important, use https because each request will force a reload.

Kelsey
Agreed. You can control the page expiration on your web server (by headers/metas or code) but you cannot do anything about client and network persistance behaviors (bowsers cache, proxies cache...).
JoeBilly
Thanks. Appreciate your advice.Just to add, the site is already using https already. And yes, like Kelsey mentioned, it is forcing a reload, but I am still able to click Resend (on firefox) and the posted data will be resent as a result and the page is reloaded with the data. On a page without any posts, it is not even confirming and just displaying page as it was.I did more lookups, and seems like this is a common question, but without a true solution. Hacks like the javascript I mentioned originally seems to be the most suggested workaround so far. I guess there isn't any other known way?
K2so
A: 

After much time spent on investigations and trials, I have implemented a workaround and decided to share it in case someone else might find it useful. This (closest to solution but only with the exception on Firefox) workaround will cause:

  1. IE6 - 8: "Page expired" comes up
  2. Chrome: "Confirm Form Resubmission" comes up
  3. Firefox: A dialog box would come up asking to resend the post data

Workaround:

  1. With the Response.Cache settings listed in the original problem posted above
  2. Change all hyperlinks to a different page within the site to LinkButton.
  3. Set the PostBackURL in the LinkButton to the link href URL.This is necessary, because only with POST, along with the header we set, that the browser would expire the originally posted page in history and ask for a resend.
  4. Instead of using Response.Redirect in the code behind, use Server.Transfer, as Response.Redirect will use a GET to another page.

This solution does not prohibit the user to navigate back to a page in history, but whether confirm whether to post data once again. The History.Forward(1) doesn't work quite well, as mentioned in the original post, and I also recognize the possibility of automatically reposting to a page without any warnings, essentially resulting with multiple requests submitted to the server.

The main idea is to POST to every page instead of GET, and so every page visited in the site would yield to the Page Expired page when navigating back. Now the user can always refresh to repost the data.

K2so