Reload the page on hitting back button

Question 1

I have a webpage that requires login. Once a user has logged in I start the session and once he logs out I destroy it, but when I press the back page it gives me the user profile page again which ideally should not be the case as the user has logged out. However, it works fine if I reload the page after logging out.

It's a local chatroom where everybody online and logged in can chat together. There are three pages: login.php, auth.php, logout.php

login.php is the common login page containg a form. auth.php has a div displaying all previous chats up til now, a textbox and share button on clicking which a form is sent again to auth.php so everytime the form is posted the chatpost is sent to database and auth is reloaded with the latest database within the chat div..

Now the problem is once I logout I unset all the variables and destroy the session but even then if I hit the back button in browser (Safari), the previous version of auth.php without the last chat entry is visible which ideally should not as the session is destroyed. I have put a session validation in auth.php, so basically I want the auth.php to reload of the user visits it after logging out as reloading auth.php displays that "you are not logged in"

i have tried

<?php header("Cache-Control: no-cache");
header("Pragma: no-cache");
?>
and
<head>
<meta http-equiv='Pragma' content='no-cache'>
<meta http-equiv='Expires' content='-1'>
</head>

Sorry for the lengthy question but I really need help on this.

Question 2

These headers will force the browser, and proxies if any, not to cache the page and force a new request to the server for that page:

  header("Cache-Control: private, must-revalidate, max-age=0");
  header("Pragma: no-cache");
  header("Expires: Sat, 26 Jul 1997 05:00:00 GMT"); // A date in the past

Question 3

I think the behaviour you want is a behaviour that breaks the expectation of the back button for users.

Users expect that when they press back, it returns them back to the page they were previously viewing, in the state it was in when they left it. Most modern browsers achieve this by not only caching the page, but by retaining the page state (including the Javascript context) in memory so that when returning to the page via the back button, it's in the same state it was before, including anything they wrote into forms or any Javascript they interacted with.

In most browsers you can forcibly override this by setting Cache-Control headers such as no-cache and no-store. I don't know if no-store would work in your case for IE10, or if IE10 ignores even this and just goes back to the page anyway. If it did, I don't think I'd really blame it. It's doing it in the user's interest of both being fast, and of returning back to the page as it was when it was viewed before.

I think the approach that I would take, and you don't have to agree with me, is to re-think the design. Why do you require users to hit "back" if you are not going to show them the same thing they saw when they were back there? If you want to show an updated form, why not redirect after POST back to the form, which will count as a new page load and honor your Cache-Control headers? That is what I'd do and it's become somewhat of a de-facto standard.

tl;dr it's possible, but I'm not certain, that you could do what you want with no-store, but I'd be looking at moving to redirect after POST instead so as not to rely on the back button for something other than going back to the previous state.

Question 4

I have tried 3 separate things when I faced the same situation:

window.history.back()
navigator.app.backHistory();
History.go(-1);

Individually, none of these solve the problem. I put all 3 things together and much to my surprise it worked. I really don't know what is behind it.

Then I decreased to two functions and removed:

window.history.back()

Now I am using this function and it is working fine.

//Works Fine
function onBackKeyDown() {
    history.go(-1);
    navigator.app.backHistory();
}

Question 5

You can try using the HttpResponse.Cache property if that would help:

Response.Cache.SetExpires(DateTime.Now.AddSeconds(60));
Response.Cache.SetCacheability(HttpCacheability.Public);
Response.Cache.SetValidUntilExpires(false);
Response.Cache.VaryByParams["Category"] = true;

if (Response.Cache.VaryByParams["Category"])
{
   //...
}

Or could could block caching of the page altogether with HttpResponse.CacheControl, but its been deprecated in favor of the Cache property above:

Response.CacheControl = "No-Cache";

Edit: OR you could really go nuts and do it all by hand:

Response.ClearHeaders();
Response.AppendHeader("Cache-Control", "no-cache"); //HTTP 1.1
Response.AppendHeader("Cache-Control", "private"); // HTTP 1.1
Response.AppendHeader("Cache-Control", "no-store"); // HTTP 1.1
Response.AppendHeader("Cache-Control", "must-revalidate"); // HTTP 1.1
Response.AppendHeader("Cache-Control", "max-stale=0"); // HTTP 1.1 
Response.AppendHeader("Cache-Control", "post-check=0"); // HTTP 1.1 
Response.AppendHeader("Cache-Control", "pre-check=0"); // HTTP 1.1 
Response.AppendHeader("Pragma", "no-cache"); // HTTP 1.1 
Response.AppendHeader("Keep-Alive", "timeout=3, max=993"); // HTTP 1.1 
Response.AppendHeader("Expires", "Mon, 26 Jul 1997 05:00:00 GMT"); // HTTP 1.1

Question 6

First of all, giving error messages if users use Back or have to refresh a page for whatever reason, is a really bad idea. Instead, you should transparently deal with that. Think about a page not coming up fully because of problems on the transportation level - the only option the user has is to reload or go back.

To answer your question, you have to keep track of the user's navigation yourself, that means on the server side. Forget about java-script here. If the user visits a website, you can store that information in a Session associated to the user (there are several methods of keeping these unique sessions, and I won't go into details here). If you store in your internal structures which pages the user visited lately, it is easy to determine a page being visited twice, or navigation going into the "wrong" direction.

You could easily generalize this (and making the whole thing more robust, for example against users jumping wildly between urls, or going back more than one step at once) by building a graph of "allowed" navigation and traversing it while the user is visiting websites.

The correct behaviour then if the user is doing a "wrong" navigation (like stepping back, reloading == visiting twice) is to get him back on track. Not to give an error message he can't escape! As he is not allowed to reload or go back, he has no options left.

Reload the page on hitting back button

Answers

php,caching,back-button