Preventing Repeat Form Submission Using PHP Sessions Keyword Discovery
Get our FREE SEO Guide
Subscribe to our newsletter to receive useful SEO tips, tricks, strategies, free ebooks that are available only to our subscribers and get this amazing SEO guide for free!

Your email is safe and will NEVER be shared with any other parties. And of course, you can unsubscribe at any time.

Name:
Email:
SEO Elite - #1 SEO Software

Who Else Wants To Finally Get A #1 Google Ranking In As Little As 7 Days... And Drive A Minimum Of 789 Unique Visitors To Your Websites Per Day?

Keyword suggestion PHP Script

This script allow you to search for relevant keywords based on your website's main keyword

Only $9.95
Coming soon ...


Self SEO Store  
SEO forum
Website templates
Flash templates
Best hosting reviews.
Free Internet & IT Magazines.
Articles archive

Submit your article

Register
Login

Search
XML news feeds
Free RSS news reader
Contact


AddThis Feed Button

Preventing Repeat Form Submission Using PHP Sessions

Posted by Jeremy Miller on: 2005-08-31 18:39:06

Self SEO > Web Development Articles


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:

  1. Visitor requests a page from the server which has a form on it.
  2. Server retrieves form and sends to user.
  3. User enters data on form and submits to server.
  4. 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
  1. changes during the form submission process,
  2. does not depend on the specific form being submitted, and
  3. we 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:

  1. Visitor requests a page from the server which has a form on it.
  2. Server retrieves form, generates a new submissionId which is embedded into the form, updates nextValidSubmission, and sends to user.
  3. User enters data on form and submits to server.
  4. 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.






Print this article    Tell a friend
Post New Comment

This site does not allow anonymous comments. Registered members can login to participate. Registration is free and takes only a few seconds