More Redmond Developer Network Sites >>> RedDevNews.com | ADTmag.com | Events
Close

Practical ASP.NET

Suppressing the Back Button: Just Say No

I teach a couple of courses on ASP.NET for Learning Tree International (one of which I wrote). Often a participant will come up to me, usually on the third day of the course, wanting to know how to disable the Back button on the browser. I first explain that the Back button is processed entirely inside the browser and handled by the browser working its way back through a cache of pages that it's already retrieved. Since there's no trip to the server, our server-side code doesn't run. You can't disable the Back button with server-side code.

If you've read my previous columns, you'll know that I can only suppose that you could handle the problem in JavaScript. Read this discussion of the problem, which I like. But quite frankly, browsers are designed to stop you from holding the user on the page.


Staying 'Webby'

More importantly, disabling the Back button isn't "webby" behavior. To me, the request indicates that the developer is trying to move a desktop paradigm to a browser-based app. I encourage the participant to try to write their application so that it doesn't matter if the user hits the Back button.

In a browser-based application, this means that you're striving to make each page a standalone item that is completely independent of other pages. If you do that then it won't matter what page the user was on before the current page. If the user goes back to the previous page, it won't matter.

Of course, not all transactions can be fit onto one page. The Wizard control can be helpful here because it lets you handle a multiple-step process on one page. With the Wizard control, the user can move back and forward through the Wizard's steps without leaving the page.

Handling the user clicking the back button inside the Wizard control does require some planning. The key is to take no action until the user clicks on the Finish button. If the user wants to move back and forth between the Wizard's steps prior to clicking the Finish button, then there's no problem because you haven't changed anything. When the user clicks on the Finish button, you'll have access to all the data on the page in all of the Wizard's steps and can perform any updates you want -- and then send the user to a Finish step.

An ASP.NET Solution
If I can't talk you out of trying to disable the Back button, I tell my class participant's that the best way to get something like what they want is to force the previous page to expire. This solution isn't about disabling the Back button but selecting pages that you don't want the user to return to. When you force a page to expire then, when the user hits the Back button and returns to the page, the browser is forced to go back to the server to retrieve the page -- this gives your server-side code a chance to run.

Furthermore, this solution assumes that you have control over the user's previous page. The user may come to your page from another site in which case this solution won't work. It also assumes that you know what the "previous" page is, so that you can set it up to expire. If the page that the user is going to can be reached from any page on your site... well, you probably don't want to apply this solution to that many pages.

The user will also probably get a message that "The page has expired," which may not fit into your vision of your site's user interface. Back on the server you can use Response.Redirect or Server.Transfer to send the user to the page you want.

This directive, added to a page in Source view, will do the job on most browsers:

‹%@ OutputCache location="none" Duration="1" VaryByParam="none" %›
You also do it from code by calling the SetCacheability method:

Reponse.Cache.SetCacheability(HttpCacheability.NoCache)
You know what? Another choice is to put a message on the page telling the user not to use the Back button. And, yes, I have no faith in this solution, either, but I've seen lots of sites use it. But, since you shouldn't be doing trying to do this at all, I figure it's as good a solution as anything else in this column.


About the Author

Peter Vogel is a principal in PH&V Information Services, specializing in ASP.NET development with expertise in SOA, XML, database, and user interface design. His most recent book ("rtfm*") is on writing effective user manuals, and his blog on technical writing can be found at rtfmphvis.blogspot.com.

Reader Comments:

Fri, Jan 22, 2010 PeterVogel Canada

Dean: The only security-based reason that I know of (and I may just be revealing my ignorance, here) is the desire to prevent an unauthorized user from sitting down at an authorized user's unattended computer and use the back button to work their way through the authorized user's history until they get to some page that the authorized user viewed earlier (and that the unauthorized user is not allowed to see). This assumes, of course, that the authorized user left their browser open when he/she/it left their computer unattended. You probably can't talk your client out of the requirement but setting all of the sensitive pages to expire immediately (as described in the column) may be exactly what the client wants to have happen--it would prevent access to those pages by viewing the browser's history. The major disadvantage is that the URL for the page (with its querystring) is probably still going to appear in the browser's address bar even if the page itself isn't displayed.

Thu, Jan 21, 2010 Dean USA

My challenge is not that I want to kill the back button, it's that we have sites that are used by our customers' employees and some of our potential customers actually require the back button be disabled as part of the security requirements. Do you have any idea where this requirement might have originated or what convincing arguments can be used to get them to eliminate it.

Sun, Jan 10, 2010 Abbas Amiri

I always said No about this request, and now I am happy that this article published. Thank you

Tue, Jan 5, 2010 Peter Vogel Canada

Valcon: I wish that I could disagree with you (g)!--HTML/HTTP weren't designed for complex applications (and is one of the reasons that I'm exploring Silverlight). However, my clients want to be able to give their customers/employees access to complex applications and don't want to have to fondle every user's computer--so we go to the Web. The good news is that HTML/HTTP can be made to support complex occupations if you throw enough thought and work at the problem (and, fortunately for me, I'm paid by the hour).

Mon, Jan 4, 2010 Valcon The Netherlands

HTML4 is simply not supposed to host complex applications. When your application has a level of complexity which is incompatible with the Back-button, you shouldn't have build it as a web application, but as a Windows (or other GUI) application.

Fri, Jan 1, 2010 Peter Vogel Canada

Scott: I'm sure that there's a more balanced approach than my dogmatic "never turn off the back button" (though I don't think so, of course (g)). Where a transaction spreads over several pages, one excellent strategy is to not commit any changes on any page until the user gets to the last page (this is the way a well-designed wizard works, for instance). Of course, this requires keeping track of the user's state over those several pages with all of the attendant problems (e.g. discarding the state if the user abandons the transaction before getting to the last page). However, it's a strategy that does make supporting the back button easier because, if the user goes back to a previous page and changes an entry, the user is really just changing an entry in their state data.

Wed, Dec 30, 2009 Scott Simpson Boston, MA USA

Everyone has good points here. There are some intrinsic issues with writing complex web apps though that don't allow the collection of single pages approach easily. Even if you do expire pages, there is a user unfriendliness issue you can't get around. If the previous page contains data that is invalid or shouldn't be available, you have to have someone prompted to repost data, then give them some kind of "trying to access invalid data" type of message and direct them back to where they were before, or some other place. None of these approaches are what would be called user friendly. Looks like there will be other alteratives once we have full html 5 implementations in all browsers - but we'll have to wait a while for that. http://scottsimpson.us

Tue, Dec 29, 2009 Peter Vogel Canada

Apekshit: I'll need a little more information to be helpful--first: Why don't the solutions offered here (in the column and by the posters) work for you? I'm not familiar with the university's blog site so I'm not sure what restrictions you have to deal with.

Sun, Dec 27, 2009 Apekshit india

hi, I want to disable the back button on my site h DOT ttp:ignou-student.blogspot.com What can i do for it.

Fri, Dec 18, 2009 Peter Vogel Canada

Cory, I still disagree. I don't think there's anything in the definition of "an application" that says "users can't go back and change their minds". And what you're building is not just "an application" but a "Web application". In order to make your life easier you are violating the knowledge/experience/expectations that your users bring with them to that environment--making their life harder. I think what you're trying to do is make a Web application work like a Windows Form application. The result is that you're going to spend a lot of time fighting with the environment, time that would be better spent in delivering functionality to your users. I started off creating Windows Forms applications and then moved to the Web environment: I decided that the secret to success was in embracing the environment rather than trying to make behave like something I used to work in. And, by the way, Columbus went to his grave ignoring the evidence of his eyes and remained confident that he had found India when, in fact, he had found a whole new world.

Thu, Dec 17, 2009 Cory Jorgensen Edmonds, WA

Peter, I disagree with the idea of not allowing the developer to disable the back button. My application I have written is a perfect example where I don't want the user to hit the back button becuse I am writing an APP not a WEB Page. The problem I have is that your holding onto a simple perspective of what developing a web page means. Web development is growing in many different directions and having a little more control of the environment my users have access to makes it easier for me to do my job as a developer. Your explanation is like telling columbus he is an idiot because the world is flat.

Sat, Dec 12, 2009 Peter Vogel Canada

--I should never have suggested any solution and just stopped with saying you shouldn't do it . I suspect that it all comes down to your intent: If you're trying to hold the user on the page, expiring the previous page isn't the right answer (however, the user can still enter a new URL or pick a page from your Favourites list). If you're trying to prevent the user from going to the previous page (which is what I had on my mind) then expiring the page makes sense to me. But (for completeness sake) Another JavaScript solution (I'm told) is to attach this code to the Page's unload event: window.location.replace('nameOfYourPage')

Tue, Dec 8, 2009 Arun India

Best is to use the below. if(window.history.forward(1) != null) window.history.forward(1); Thanks.

Tue, Dec 8, 2009 Arun India

The first solution does not even compile the WebSite. ‹%@ OutputCache location="none" Duration="0" VaryByParam="none" %› It requires the duration to set to positive integer value. Second option, does not serve the purpose. Thanks.

Add Your Comments Now:

Your Name:(optional)
Your Email:(optional)
Your Location:(optional)
Comment:
Please type the letters/numbers you see above

Free Whitepapers

> More TechLibrary