I'm currently involved in an ASP.NET project where I need to restrict the users ability to go back in the page structure using the back button. It is essentially a wizard style navigation and I don't want to give the user the ability to go back from the last step and re-submit the data. JavaScript is not an option unfortunately, so I "solved" it by setting the HttpCacheability in every pages Load event to NoCache. This gives the user the "Page expired" page when he or she clicks the back button. It isn't very elegant at all, and I'm wondering what other options I have to achive the desired results.
-
5Re-design. Any website design that can't cope with the back button is seriously broken. Please don't inflict it on the world. How about making it so that they can submit the same data twice and your back end will just do the right thing? That's a much more usable solution. – Michael Kohne Oct 13 '09 at 18:25
-
That is actually a very good point. Currently I do have that part covered because the services won't be hit with another request, so restricting the use of the back-button might actually be overkill and quite un-necessary. – Henric Oct 13 '09 at 18:31
-
See: http://stackoverflow.com/questions/87422/disabling-back-button-on-the-browser – Shog9 Oct 13 '09 at 18:33
4 Answers
Keep the navigation state on the server side, and if the user hits a page that doesn't correspond with a next/prev click, redirect them to where they were supposed to be.

- 31,467
- 8
- 60
- 69
Only expose one URL for your entire wizard. The step displayed will depend on session state, which can store what steps they have already completed.
That way there is no "invalid" URL for the user to load.
You should probably consider creating a UserControl for each step. You then place all the steps on a single .aspx page and show and hide them as appropriate.

- 7,189
- 4
- 34
- 51
-
This is the way I need to go I think. I need to expand the current functionality instead of altering the browser's base functionality, as Matt discourages below. Thanks all. – Henric Oct 13 '09 at 18:27
-
If your wizard uses full postbacks this isn't a viable solution, you can still use the back button to redo posting data. If you run an ajax application, this is viable. – Chris Marisic Oct 13 '09 at 18:48
-
I'm not certain why full postbacks would matter. With the step information stored in session, the code would always be able to determine what step the user should be on. – Jason Berkan Oct 13 '09 at 19:06
-
My point was if he was trying to use his state saving functionality to determine which user controls are displayed the back button will still allow the user to have access to the previous controls so my point stands that you need to verify their current step vs where they're supposed to be on every postback. – Chris Marisic Oct 14 '09 at 13:39
The short answer is "you can't." Because it's browser-side functionality, any method to do this will be via something exposed by the browser, which means it's trivially defeatable. The long answer is you don't want to. This creates usability issues (any changes to normal browser behavior is undesired). I would suggest using a session cookie to determine where in the process they should be and issue a 302 redirect to the appropriate page if they try to access the wrong page of the process (prior to processing any GET/POST data as well as discarding any data they may have been submitting). Trying to defeat the users by altering how the browser's base functionality works will always lead to headaches.

- 509
- 2
- 5
It's not possible. Even if you get it working in internet explorer in Firefox it will not work.
The only way to handle this is you need to handle saving the state of a users step in either their session, database etc and then when they submit verify that they are submitting on the correct step.

- 32,487
- 24
- 164
- 258
-
I have created a separate class which I store in a strongly typed session that has a previous page property so that navigation is only allowed between certain steps, and not just jumping in anywhere without completing the required stepd. – Henric Oct 13 '09 at 18:24
-
The issue is if the user uses firefox you will get no events fired when they use the back button because it uses perfect in memory caching that it will not fire an expired page event or pageload event so even with your custom class it won't do anything unless you verify on the submits where they are currently and where you expect them to be. – Chris Marisic Oct 13 '09 at 18:50
-
Thanks Chris, I have now surrendered to the idea that i have to let the page display old data when the back button is hit. They can't, as I originally stated in my post, be sent again since the cached data that has been collected from the user is cleared once the user gets to the last step. I could get around by simply clearing out the form before redirecting to the last page. – Henric Oct 13 '09 at 20:15