We've all seen those messages on some websites warning not to click a button more than once or negative consequences, like paying a bill twice, may result. Sometimes we can cause these problems by hitting the back or refresh buttons. In this article I will explain a methodology whereby a site can ensure each form is submitted only once, thereby demonstrating that such warnings are unnecessary and, depending on the nature of the problems caused, worth repairing immediately. Let's begin by taking a look at the process we are studying: Form Submission. As pedantic as it may seem, it will be worthwhile to detail each of the steps in this process: Visitor requests a page from the server which has a form on it.Server retrieves form and sends to user.User enters data on form and submits to server.Server processes form data and returns resultant page. The scenario we now need to analyze is when the user re-triggers a previous form submission process. What we need to find or create is something which changes during the form submission process which does not depend on the specific form being submitted and which we can tell changed. That was a loaded sentence which fully details our solution, so let's break it down. Find or create something which changes during the form submission process,does not depend on the specific form being submitted, andwe can tell changed.

Since the item which changes does not depend on the form being submitted (e.g. it doesn't matter if it's a newsletter registration form, customer signup form, payment form, etc.), the item is not something which already exists and therefore must be created, so let's create a form variable called submissionId and assume it has the 3 properties mentioned above. So far, so good -- or so it appears! The third "property" is that "we can tell [it] changed", but "changed" is not a property of a variable, so we need to look at this more closely. In order to tell something changed, we must have a reference point, an answer to the question "changed from what?" This is where a session variable will come into play. If we define a session variable, say $_SESSION['nextValidSubmission'] and treat it as a reference point, we will have all of the tools necessary to protect our visitors. The idea will be to keep the session variable updated with the last submissionId sent out and change the submissionId each time it is sent out to the user. Then, if they try to resubmit the data, they will be submitting an old submissionId which doesn't match nextValidSubmission and we will know not to re-process this data. Let's look at this in terms of the processes: Visitor requests a page from the server which has a form on it.Server retrieves form, generates a new submissionId which is embedded into the form, updates nextValidSubmission, and sends to user.User enters data on form and submits to server.Server processes form data, changes nextValidSubmission, and returns resultant page. Now, if the visitor somehow resends the data, they will be sending the old submissionId which will not match the new nextValidSubmission. So, you can now say goodbye to relying on javascript to remove/disable buttons, silly warning messages, and upset customers by preventing form re-submission.

Webmaster of Script Reference - The *NEW* PHP Reference & Tutorial Site For Non-Programmers
See here for more detailed information, an example using PHP, and an alternate method which doesn't require sessions.