Restricting the use of back button without JavaScript

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.

13.10.2009 18:16:28
Re-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 13.10.2009 18:25:17
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 13.10.2009 18:31:07
Shog9 13.10.2009 18:33:20

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.

13.10.2009 18:28:08
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 13.10.2009 18:27:30
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 13.10.2009 18:48:29
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 13.10.2009 19:06:25
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 14.10.2009 13:39:35

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.

13.10.2009 18:21:12
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 13.10.2009 18:24:23
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 13.10.2009 18:50:45
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 13.10.2009 20:15:44

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.

13.10.2009 18:21:36

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.

13.10.2009 18:22:54