What methods are available to stop multiple postbacks of a form in ASP.NET MVC?

Question

A common web problem is where a user clicks the submit button of a form multiple times so the server processes the form more than once. This can also happen when a user hits the back button having submitted a form and so it gets processed again.

What is the best way of stopping this from happening in ASP.NET MVC?

Possibilities as I see it are:

1. Disable the button after submit - this gets round the multiple clicks but not the navigation
2. Have the receiving action redirect immediately - browsers seem to leave these redirects out of the history
3. Place a unique token in the session and on the form - if they match process the form - if not clear the form for a fresh submit

Are there more?

Are there some specific implementations of any of these?

I can see the third option being implemented as an ActionFilter with a HtmlHelper extension in a similar manner to the anti-forgery stuff.

Looking forward to hearing from you MVC'ers out there.

Answer 1

This really isn't MVC specific, but the pattern we follow on our web pages is that actions are performed with AJAX calls, rather than full page POSTs. So navigating to a url never performs an action, just displays the form. The AJAX call won't be in the history

Answer 2

Along with the disabling of buttons, you can add a transparent div over the entire web page so that clicking does nothing. We do this at my work and add a little friendly label saying processing request..

Answer 3

You should always return a redirect as the HTTP response to a POST. This will prevent the POST from occuring again when the user navigates back and forth with the Forward/Back buttons in the browser.

If you are worried about users double-clicking your submit buttons, just have a small script disable them immediately on submit.

Answer 4

You might want to look at the Post-Redirect-Get (PRG) pattern:

Answer 5

Often people overlook the most conventional way to handle this which is to use nonce keys.

You can use PRG as others have mentioned but the downside with PRG is that it doesn't solve the double-click problem, it requires an extra trip to the server for the redirect, and since the last step is a GET request you don't have direct access to the data that was just posted (though it could be passed as a query param or maintained on the server side).

I like the Javascript solution because it works most of the time.

Nonce keys however, work all the time. The nonce key is a random unique GUID generated by the server (also saved in the database) and embedded in the form. When the user POSTs the form, the nonce key also gets posted. As soon as a POST comes in to the server, the server verifies the nonce key exists in its database. If it does, the server deletes the key from the database and processes the form. Consequently if the user POSTs twice, the second POST won't be processed because the nonce key was deleted after processing the first POST.

The nonce key has an added advantage in that it brings additional security by preventing replay attacks (a man in the middle sniffs your HTTP request and then replays it to the server which treats it as a legitimate).

Answer 6

If I understand it properly, the nonce is generated on form.asp for example. And once POSTed, the form_process.asp page looks for the nonce. If it has it and it matches something in a database, it processes. Otherwise it fails. Is this correct in terms of where the nonce is generated, used, and how the process page understands it?