How to handle multiple submissions server-side

Question

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.

Swastika

The consensus certainly seems to be that this is what the rest of us fine programmers (and me!) use :-) It is a powerful and robust technique, with security benefits in most applications. – Cotenant

This is similar to the question <a href="#130837 do you prevent a user from posting data multiple times on a website</a>. – Manuel

Answer 1

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.

Cotenant

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? – Zoie

@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 – Smog

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? – Hertel

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. – Oona

Answer 2

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.

Woodnote

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? – Sinistrorse

I really think this must be the best solution, the req I'd needs to be generated when the form is generated – Spoofery

Answer 3

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.

Prolific

Answer 4

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.

Saire

Answer 5

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.

Alexina

Answer 6

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.

Necropolis

Wrong. If I click frantically on the submit button, you'll get multiple POST requests submitted. – Partite

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. – Necropolis

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 https://mcmap.net/q/411190/-do-we-still-need-backup-code-for-people-who-have-javascript-disabled-closed). "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. – Partite

PGR pattern prevents against page reload, but not against double click. – Hertel