tags:

views:

393

answers:

5

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.

+10  A: 

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
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?
jayrdub
@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
+3  A: 

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
A: 

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
+2  A: 

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
A: 

This is similar to the question How do you prevent a user from posting data multiple times on a website.

Rontologist