0

I'm facing issue because of Browser's cache in We Application.

On LogoutButton Click I clear the Session and Cache in the following way.

Session.Clear();
Session.RemoveAll();
Session.Abandon();
// Code disables caching by browser.
Response.Cache.SetCacheability(HttpCacheability.NoCache);
Response.Cache.SetExpires(DateTime.UtcNow.AddHours(-1));
Response.Cache.SetNoStore();
Response.Redirect("LoginPage.aspx", false);

and I'm disabling the Back Button also.

But If I access the History, User is able to get access to all the pages even after LogOut also.

In the latest Version of FireFox I have observed that It does not allow for Back Button, But When U long press the Back Button Firefox shows You the History means Previous Pages and When User clicks on it , It says some try again message and When User clicks on Try Again Message, then User is redirected to the given Pages and On Web Application It shows the Name of Old User name, for which I have just logged out recently.

In Google Chrome also I'm facing the same Issue.

One More thing I have observed that, in FireFox When User clicks Try Again. It hits the Login_ButtonClick Method of Login Page and Submits the credentials and that is why User is able to log in.

So I have come to this point and I have to find out some way so that browser does not cache my web application page because I'm not using Caching in application and performance is not a concern for me.

Or If I can do this in some other way, please let me know.

  • Can u please explain by code –  Nov 05 '14 at 19:12
  • Is a little bit of JavaScript allowed? Of course you also have to do something server side (using a token as suggested by Insta) but at least client side you can redirect _automatically_. Try a technique similar to what described here: http://stackoverflow.com/a/24058288/1207195 – Adriano Repetti Nov 05 '14 at 20:16

4 Answers4

0

If this is for authentication, stop rolling your own and use Forms Authentication.

If you're going to continue rolling your own, then set a value in your session for "session token", just use Guid.NewGuid(). Set a cookie to this same value. On the logout code, set the session token value (in the session) to null.

Every single page request, compare the cookie value to the session value. If they are ever different, log the user out automatically, and send a cookie to blank out the cookie value as well.

Bryan Boettcher
  • 4,412
  • 1
  • 28
  • 49
  • I want to disable caching throughout the application so that browsers can not cache any pages and User should not be able to view any page after logout from the application any how. –  Nov 05 '14 at 19:07
  • What do u mean by this? send a cookie to blank out the cookie value as well. Can you please explain by code. –  Nov 05 '14 at 19:09
0

I do not think it is possible to achieve what you're looking to do, this history in the browser is actually a cached version of the content your server sent to the browser. At best you can tell the browser to request content that's not cached on the server with the headers pragma: no-cache, but it is not bound to honor it by any means

Louis
  • 593
  • 4
  • 13
0

Try adding tags to the HTML to prevent caching as well. Sometimes it works, sometimes it won't. I've had to use a combination of server and client side code to get a page not to cache (actually, refresh when the user hits the back button).

EDIT

Try adding these to your header in the HTML:

<meta http-equiv="cache-control" content="max-age=0" />
<meta http-equiv="cache-control" content="no-cache" />
<meta http-equiv="expires" content="0" />
<meta http-equiv="expires" content="Tue, 01 Jan 1980 1:00:00 GMT" />
<meta http-equiv="pragma" content="no-cache" />

Kind of brute force, I'll admit, but with some browsers you've got no choice but to use this approach.

Tim
  • 4,051
  • 10
  • 36
  • 60
0

No matter what headers you use some browsers seem to always cache!

I just came up with this solution that I myself was looking for. It was staring me in the face the whole time.

This does not stop the browser from caching the data, it only stops the stale data from being re-read from the cache after the page has been reloaded. You can still use those headers if the data is sensitive and never want it written to cache, but it will not work in ALL cases. In my application that is not necessary I want to only avoid loading stale data from the browsers cache.

this solution is AMAZINGLY simple and requires little expertise to implement .

I use php but I believe URL variables can be used with asp, javascript and much more

Your browser sees http://example.com/index.php , http://example.com/index.php?x=32 and http://example.com/index.php?x=3199 all as different URLs so it will not use any of the above URLs as a cache for the other.

I generate a random number in PHP which you can probably do in ASP

in php I use:

$rand=(rand(1, 99999));

Now my link in PHP (should be easy to understand even with limited PHP)

'<a href="http://example.com/index.php?rand='.$rand.'>"

If the page already has URL variables then we add it to any GET forms, or concatenated links.

If the Forms are post forms we tag it along the "action" URL, so

http://example.com/index.php 

becomes

http://example.com/index.php?rand=<?php echo $rand;?>

Then any page I do not want cached I simply add this random number as a URL variable. That URL variable is not handled by the server at all , I never GET that number and do not need to.

http://example.com/index.php?rand=4398 next time we load the same page the browser believes it is a different page due to the different rand= URL variable.

No worries we never have to read it, it is only to "fool" the browser. The next timne we go to the same page we will most probably see a very different number

http://example.com/index.php?rand=55468

or as far as your browser is concerned, NOT the same page, even if we completely discard the variable back at the server , meaning it has no value in your ASP or PHP and never used as a variable.

The answer is now so simple I am surpries I spent weeks on this and nothing worked consistently. THIS DOES!

Mark
  • 39
  • 1
  • 6
  • Bryan Boettcher no need to mess with sessions at all. In fact I am a firm believer that "rolling your owm" reduces hacking. They know the vulneabilities of existing scripts. Tim that does not work on all browsers. For you both , my soluton works on ALL browsers – Mark Mar 10 '19 at 05:49
  • `No matter what headers you use some browsers seem to always cache!` Which browser caches when you use `<%@ OutputCache NoStore="true" VaryByParam="*" Location="None" %>` at the top of an aspx page? I am not aware of any? Have you tried that? – mjwills Mar 10 '19 at 06:05
  • `Tim that does not work on all browsers` No it doesn't. It won't, for example, if the same random number is generated. The solution is for the server to **correctly** inform the browser not to cache the content. This is a well established solution in ASP.NET. – mjwills Mar 10 '19 at 06:06
  • we have had to do this. Chrome was caching a redirect link and using the old url even after a new one was in the database. We had to trick it with extra numbers. We also have to do this whenever we change our core javascript files. +1. – John Lord Jul 11 '19 at 19:56