CODEWITHSUNDEEP
c#asp.netback-buttonbrowser-history
Mridul Raj
Mridul Raj

Reputation: 999

How to prevent logged out user from revisiting previous page using back button in asp .net?

My asp .net application is facing issue where logged out users are using browser's back-button to revisit previously accessed page. User cannot perform any server side events , but it would be much better if user are not allowed to view this page at all. I searched for a solution to stop this but most of the solution include writing code inside page that must be not be revisited like this one.

 protected override void OnPreRender(EventArgs e)
        {
            base.OnPreRender(e);
            string sb;
            sb = "<script language=javascript>\n";
            sb += "window.history.forward(1);\n";
            sb += "\n</script>";
            ClientScript.RegisterClientScriptBlock(Page.GetType(), "clientScript", sb);
        }

This means that i will have to write code in every page that a logged-in user can visit . Is there a better way to handle this issue? Im expecting an optimized solution whereby I will not have to write code in every page . Help will be much appreciated.

Upvotes: 1

Views: 5874

Answers (3)

Blachshma
Blachshma

Reputation: 17385

Based on your question, I understand you only want to prevent the usage of the Back button (to see previous data), but that your server-side works correctly and doesn't allow logged-out users to perform any tasks...

If this is not the case, you should also add validation in your server side to make sure that a logged out user (which should be treated just like a user who never logged in) cannot do anything that requires permissions...!

Back to your question - you should disable caching in the browser.

In CodeBehind:

Response.Cache.SetNoStore();
Response.Cache.SetExpires(DateTime.UtcNow.AddHours(-1));
Response.Cache.SetCacheability(HttpCacheability.NoCache);

You can also use META tags in the ASPX page:

 <META Http-Equiv="Pragma" Content="no-cache">
 <META Http-Equiv="Expires" Content="0">
 <META Http-Equiv="Cache-Control" Content="no-cache">

This will tell the browser that the page should not be cached and will not be reshown via the Back button

If this isn't enough, you can also use JavaScript to clear the history, here is an example

Edit: And if you want this code to appear only once, you can create a BasePage (that derives from Page) which has this logic. Then, any page in which you want this logic should derive from the BasePage instead of the regular System.Web.UI.Page

Upvotes: 6

Aniket Inge
Aniket Inge

Reputation: 25695

with the solution mentioned by @Blachshma, you can also have a GET variable that contains the timestamp of when the page was fetched. Then, in the Page_Load() event you can check if the timestamp was the same as the current timestamp. If it is not, you refresh or redirect the page(in your case to login page) This is how GMAIL does it IIRC.

Remember to put the time-check inside if(!IsPostBack) in Page_Load() event.

Upvotes: 0

Shriram Shrikumar
Shriram Shrikumar

Reputation: 1155

Assuming that every page that is restricted checks that the user has access to that page, the problem you are having boils down to caching. If you do not check if the user is logged in, there is no way around it - you have to check on each page to be secured. Otherwise, it is a security hole.

Think about it this way. The page that the user visited, was saved to their computer so that it can be rendered to the user. The user then logged out. The previous page is still there on their computer as part of the browser cache.

In this case, there is nothing particularly wrong with the user being able to view that page again. If you want to secure this page, you have request the browser to not cache this page.

You can use meta tags to achieve this. .NET may have other ways to getting this done.

Do bear in mind that this will mean that every page which is set to be not cached will come back to the server each time and will be noticed to be slower. It will also put additional load on the web server. Depending on how busy your site is, this may not be an issue.

Upvotes: 0

Related Questions