38

We all know the good old "disable the submit button" trick but what are the best ways to handle multiple submissions server side? I have an application where it is absolutely critical that a form only be sent once - it processes a credit card. I didn't write how it is right now but as a quick fix I threw on the disable-on-submit technique, however some impatient users that have javascript disabled are still getting charged twice.

So, what are ways to avoid this? I can think of a few - I have used a few in the past - but I'd like to see if there's any "best practices" on how to tackle this one. I am using PHP but I'm more interested in concepts.

edit: I am aware of the token technique and it is what I have used in the past, this question is more or less to see if my approach is in line with what the rest of you fine programmers use.

Paolo Bergantino
  • 480,997
  • 81
  • 517
  • 436

6 Answers6

32

One really effective way is to submit a token along with the request, and keep a list of used tokens. If the token is not valid, or the token has already been processed, then abort.

The token can be as simple as an incrementing integer, stored in a hidden text field, or you can encrypt it to increase security. This feature can be made more robust by generating the token when the page is created, encrypting it, then confirming the token has been generated AND has not been processed.

RB.
  • 36,301
  • 12
  • 91
  • 131
  • 2
    How do you handle a user pressing the back button (most browsers don't re-request), changing the data in the form, and submitting the same token again? – JeremyWeir Aug 19 '10 at 23:06
  • @jayrdub I know this q was for RB, but I simple give an error, saying session expired, then lead them back to the form, loading the form fields with data saved in session to decrease user inconvenience – abel Oct 07 '10 at 14:11
  • I have seen some people suggestion to store the token in a session and then compare the token to it, and if equal unset session and continue request, otherwise aboard. I think this would be still vulnerable to raise conditions, right? Do you recommend to store your "list of used tokens" in a database and check for existence with transactions? – Adam Jul 26 '19 at 14:05
  • I tried the hidden input token solution, but it didn't work because if I go back after a submission, some of the fields, including the hidden input token is reset, meaning it will be considered a new submission. I don't know why some inputs are reset, while some are preserved. – James T Nov 04 '22 at 13:04
11

Include a random unique token in a hidden form field. Then on the backend, you can check if it's been submitted before.

This is a generally good idea because it helps you defend against XSS attacks as well.

David
  • 3,177
  • 1
  • 18
  • 15
  • 1
    That's what I'm doing on my site; JavaScript populates a hidden field with a random 32-character string and I check to see if it has been submitted before. This also works for when JS is disabled because I check if the field is empty. However, what stops someone from inspecting the element and pasting in a 32-character string? – Matthew Aug 28 '17 at 22:34
  • I really think this must be the best solution, the req I'd needs to be generated when the form is generated – TalesMGodois Jan 10 '23 at 16:10
9

You might also simply test whether an identical transaction has been made in the last minute (or second, depending on the latency of your server). Most people do not buy two identical books (or whatever) within a minute of each other using the same card. If you keep a cache of credit card payments in the last minute and check whether the one you're about to make is identical (same card number, same amount) to one you've just done, chances are you'll spot the duplicate.

Keith Lawrence
  • 301
  • 2
  • 6
3

I wouldn't rely on anything client side for this. Why not generate a unique ID for this transaction server-side before presenting the client with the submit button? The client then has to submit this token back, and you check server side that every token is submitted once.

The token can, as other people said, can be an incrementing integer (+ username), or a GUID.

ripper234
  • 222,824
  • 274
  • 634
  • 905
0

I am having a similar problem. After reading this, I am thinking a token might be the way to go. This post shows a good example of implementation.

Community
  • 1
  • 1
NateShumate
  • 292
  • 1
  • 8
-7

No need to generate unique tokens and all that jazz. After form validation passes, simply redirect the visitor to another page that says something like "Your credit card is being processed". If the visitor reloads the page they are reloading the redirected page, not the POST submission.

Jake Wilson
  • 88,616
  • 93
  • 252
  • 370
  • 5
    Wrong. If I click frantically on the submit button, you'll get multiple POST requests submitted. – Clement Herreman Jan 24 '13 at 15:18
  • Have you considered just disabling the submit button once someone clicks it but before the form is submitted? That would make it impossible for someone to actually click the button more than once. The only way they could do it is if they were deliberately using Chrome Dev Tools or Firebug to alter the client side HTML and scripts with the intent of submitting more than once. The typical user would not have the knowledge or desire to do this. – Jake Wilson Jan 24 '13 at 17:17
  • 3
    Client-side is not enough to prevent critical errors, like charging a client twice (or more). What if the last deployed version of js files has an error, and the button isn't disabled, as no javascript is executed due to the error? What about people who disable javascript, not always by choice, like visually impaired people (see http://stackoverflow.com/a/2905104/135494). "All that jazz" might be good enough for the average website, but the OP stated that "*it is absolutely critical that a form only be sent once*", and without the "jazz", then it's not enough. – Clement Herreman Jan 25 '13 at 08:51
  • PGR pattern prevents against page reload, but not against double click. – Adam Jul 26 '19 at 14:22