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

• http://www.4guysfromrolla.com/webtech/111500-1.shtml

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 ... 

Acacio, 

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)
        return;

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.

Regards,
João Rosado

Joao,

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 :-)

Just some additional info: put it in the preparation of every screen (or in the master page) and the caching is disabled

Hi

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:



---

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.

Cheers,

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:  
 Nice, but that probably won't work in "older" browsers ... take care implementing HTML5 stuff !