Question

There are many interesting articles on the Post Redirect Get pattern for example here: http://www.theserverside.com/news/1365146/Redirect-After-Post

But here’s a simple question…

If the user does POST and is redirected to a GET. Fine if they hit refresh the browser just sends GET, easy to understand. But if the hit the BACK button after the GET and then hit refresh they can surely hit the POST again? yeah?

I am trying to understand how we can be 100% sure the POST can never be resubmitted?

Answer 1

One method for ensuring that a POST is not resubmitted is have a unique identifier associated with that post session, for example, if it’s a shopping cart, when they begin checking out, generate a unique ID for that process. Once the checkout has completed (e.g. POST has been sent), remove that ID from the ID’s that can be used.

You could also do this by generating a unique key with the form, and if the form is submitted, remove that key from where it is stored.

<input type="hidden" name="key" value="<?php echo generateUniqueKey(); ?>" />

where the generateUniqueKey() function will query a table and insert a unique ID, then return the ID. On the page where you are processing the form, do something like this:

<?php 
    $key = $_POST['key'];
    if (isKeyStillValid ($key)) {
        markKeyAsInvalid ($key);
        // Process form ...
    }
    else {
        die ("You have already submitted this form".);
    }
?>

Where the isKeyStillValid() function will check the database to ensure the key used with the form is still a useable key, and the markKeyAsInvalid() function will remove the key from the database.

Update:
Here’s an example that I just made which involves exactly what I described earlier. This is a very simple example, and simply uses an auto-incrementing ID in a SQL table as the key, but it should be sufficient as an example. Realistically, you would want something more thought out than this.
http://alexloney.com/post/