Avoid back button usage

Avoid back button usage

To avoid a backbutton activity, on the internet I found this :


You need to force the cache to expire for this to work. Place the following code on your page code behind.

						How do I create this in OutSystems ??

Found it here http://stackoverflow.com/questions/961188/disable-browsers-back-button and here http://stackoverflow.com/questions/533867/whats-the-best-method-for-forcing-cache-expiration-in-asp-net
Hi Joop,

although I don't know if that will solve your issue or not... to do that in OutSystems you just need to make an extension action, and call it at the Preparation action.

The easiest way to access the Response object (without being bound to the OutSystems runtime framework) is through HttpContext.Current.Response, so your piece of code would be:


Done some investigation and it only becomes more fuzzy to me what to use ... http://www.web-caching.com/mnot_tutorial/how.html
And here how to set Expired in the response heade rin IIS7 http://technet.microsoft.com/nl-nl/library/cc770661(v=ws.10).aspx

This is the header so far:
<meta http-equiv="Pragma" content="no-cache" >
<meta http-equiv="Expires" content="Thu, 15 Apr 2010 20:00:00 GMT" >
<meta http-equiv="Last-Modified" content="Fri, 4 May 2012 9:51:16 GMT" >
<meta http-equiv="Cache-Control" content="no-cache, no-store, must-revalidate, post-check=0, pre-check=0, max-age=0" >
<meta http-equiv="ETag" content="A1D14893600EE5C8C56B3382F5EE7EE3" >

But up till now no luck

Did anybody figured out a nice (working) way to set the headers so that there is NO caching ??
I doubt it would ber possible 
(even if you can work it in IE, chances are Opera, FF, Safari or chrome will handle it slightly different)
Not to mention, users can revert back to old version which contain bugs to prevent no-caching

still, you can always add:  Cache-Control -> private
One way you could do it is to include the time the page was generated in the page and then use some javascript to compare the local time to the time the page was generated. If the time is different by a threshold then the page has come from a cache. The problem with that is if the client machine has its time set incorrectly, although you could get around this by making the client include its current system time in the request to generate the page and then send that value back to the client.

and don't forget to make the timestamp secret/encrypted so they cannot alter it :)

btw, that js is not 100% ofcourse, they can turn of javascript, but the page won't work at all me thinks :)
another tip: http://monket.net/blog/2010/02/detecting-when-a-page-is-loaded-from-the-browser-cache/ with cookies this time
I found yet another link which discusses some stuff.
I am still posting it because it essentially contains something that is universally true:
In fact, this is one of the most commonly asked questions on the ASPMessageboard and, sadly, the answer is quite simple: You CANNOT disable the back button of the browser.
The problem is that, when it comes to links, the browsers pretty much respect the request headers - so if a request indicates "no-cache" or "private", new accesses will be made. However, the back button is a special case: it seems to pretty much avoid going online for as long as it can.
Actually, very recently, I was confronted with the opposite problem in a support case: Chrome was not reloading from cache when hitting back, but instead forcing a new request. That led me to open an issue with Chrome (problem had to do with invalid SSL certificates). You could say that this is a workaround (deploy an invalid certificate and force use of Chrome) but it seems to me to be wrong, in principle and form.
So this means that there is no centralized way of disabling the back button. In time I tested multiple approaches and non solved the problem. So this time I thought better - the approach to use should be the opposite - detect that the back button was used and act on it.
One possibility is to use Javascript against a session variable - check the attached example. 6.0 makes it easier: you can simply put the web-block in the layouts (if you want it centralized). The downside is that it does not work with Javascript disabled - but then again, most pages with OutSystems will not, so it should not be an issue.
n my example I chose to give feedback that Back is forbidden - but you may act on it by redirecting to an error page, forcing reload... 

Note that this method is not officially endorsed by OutSystems - even though the only downside I can think is that there will be a second Ajax request for every hit on a page with the web-block in it.

Thanks Acacio for answering with a Not Offical OutSystems answer .... however this is not the action I want to achieve.

I want to avoid that the user could use BACK to go to previous screen.
Try it yourself by logging in into an OutSystems application. Go to some screen. Select Logout and then do BACK ... you get back to the last page (just before logout). This should not be possible hence you logged out so the session should be disabled etc etc ... and must return to a (the) login page due to authentication problems.

I've found something working but still it flashes the previuos screen ... 

Whilst working on the RichWidgets feedBack block i found this little code snippet

//Prevent messages from showing when the user clicks the browser back button
    if (osjs.loadedFromBrowserCache)
Isn't this the solution to the problem .... can't I use a little jQuery to avoid BACK-buttonning :-)
Or even better  :
// Detect whether or not we are loading this page from the browser cache
osjs(function($) {
    var CACHE_COOKIE = 'pageLoadedFromBrowserCache';
    osjs.loadedFromBrowserCache = (document.cookie.indexOf(CACHE_COOKIE + "=true") != -1);
    document.cookie = CACHE_COOKIE + "=true;path=/";
In combination with the above variable ...
Hi Joop

Actually the "logout" problem is not really an issue.
Yes, the user can see the previous page he seen, but if he clicks anything or any ajax request is triggered the user will be kicked to the login screen.
It's not like he gets back a valid session.

This Back button issue is very frequent, and any workaround/hack is really not the way to go.
Users should be free to navigate back as much they want, and the applications need to be robust enough to handle invalid operations. Not the other way around.

Even on sensitive operations, for example "Online Shops". This back button issue is the same as the big warnings many pages show saying "Click only once!"
Why? The application should be build to handle that. If the developer is aware enough to warn about it, something is terribly wrong.

João Rosado

I'm not completely confinced with your answer. In fact all online bank application don't allow people to use the back button.
If you do, you'll go to a special page. And If you're logged out, you can't see the previous page !
This is done for security reasons: imagine this: you're are working on your bank account you transfer some money and you log out. Somebody else gets behind your pc and pushes the back button and see information which is not for his eyes ...
And that's the reason for us to get the back button "disabled" we're building a very secure client portal :-)
Try this extension it disables the client cache.
Just some additional info: put it in the preparation of every screen (or in the master page) and the caching is disabled

Niek: thanks for sharing this extension. I have had a long struggle in the past trying to disable cache at browser level, but it seems that I had failed to force one of the headers.

For the record, what the extension shared by Niek does is:

            HttpContext.Current.Response.Expires = -1;
            HttpContext.Current.Response.ExpiresAbsolute = DateTime.Now;
            HttpContext.Current.Response.CacheControl = "no-cache";


This solution still poses one problem, though. It does not disable back (nor tries to cope with it) - it transparently makes back behave as a new request to the previous page. To protect the use-case in which we want to avoid a user hitting back and seeing details of the end-user session, it works perfectly.

But if a user hits back and goes back to a page that actually does stuff when loading with GET, those things will be done again. So pages built to avoid loading cached content with back must be very well protected not to do anything in the preparations / late-loads and similar patterns. This could pose other problems (e.g. in the banking account, this could trigger duplicate operations inadvertedly).

Finally, thank you (Niek and Joop) for insisting with this :-) - I am very happy that at least it is possible to force browsers (I tested with IE, Firefox, Chrome, Safari) to not reload content from cache with back.

There's a new solution for this problem based on HTML5's storage feature.

Checkout the detailed explanation: http://www.sitekickr.com/blog/back-button-browser-cache/
Gonçalo Veiga wrote:
There's a new solution for this problem based on HTML5's storage feature.

Checkout the detailed explanation: http://www.sitekickr.com/blog/back-button-browser-cache/
 Nice, but that probably won't work in "older" browsers ... take care implementing HTML5 stuff !