[ACCEPTED]-Preventing double HTTP POST-post

While JavaScript solutions can disable the 26 submit button after it has been clicked, this 25 will have no effect on those people who 24 have JavaScript disabled. You should always 23 make things work correctly without JavaScript 22 before adding it in, otherwise there's no 21 point as users will still be able to bypass 20 the checks by just disabling JavaScript.

If 19 the page where the form appears is dynamically 18 generated, you can add a hidden field which 17 contains some sort of sequence number, a 16 hash, or anything unique. Then you have 15 some server-side validation that will check 14 if a request with that unique value has 13 already come in. When the user submits the 12 form, the unique value is checked against 11 a list of "used" values. If it exists in 10 the list, it's a dupe request and can be 9 discarded. If it doesn't exist, then add 8 it to the list and process as normal. As 7 long as you make sure the value is unique, this 6 guarantees the same form cannot be submitted 5 twice.

Of course, if the page the form is 4 on is not dynamically generated, then you'll 3 need to do it the hard way on the server-side 2 to check that the same information has not 1 already been submitted.

Most of the answers so far have been client-side. On 5 the server-side, you can generate a hidden 4 field with a GUID when you first produce 3 the form, and then record that GUID as a 2 submitted form when the post is received. Check 1 it before doing any more processing.

Whenever a page is requested from the server 11 , generate a unique requestToken , save 10 it in server side,mark status as NOT Processed 9 and pass it along with the current requested 8 page. Now whenever a page submit happens 7 , get the requestToken from the "POST"ed 6 data and check the status and save the data 5 or take alternate action.

Most of the banking 4 applications use this technique to prevent 3 double "POST"ing.So this is a time proven 2 & reliable way of preventing double 1 submissions.

A user-side solution is to disable the submission 4 button via Javascript after the first click.

It 3 has drawbacks, but I see it often used on 2 e-commerce websites.

But, it won't never 1 replace a real server-side validation.

Client side techniques are useful, but you 9 may want to couple it with some server side 8 techniques.

One way to do this is to include 7 a unique token in the form (e.g. a GUID or similar), so 6 that when you come to process the form you 5 can check to see whether the token has already 4 been used, preventing a double submission.

In 3 your case, if you have a table with event 2 visitors, you might include this token as 1 a column.

A client-only solution won't be enough, as 11 stated in many of the answers here. You 10 need to go with a server-side fail-safe.

An 9 often overlooked reason that disabling the 8 submit button doesn't work is, the user 7 can simply refresh the submit target (and 6 click OK on the "are you sure you want to 5 resubmit the POST data?" dialog). Or even, some 4 browsers may implicitly reload the submitted 3 page when you try to save the page to disk 2 (for example, you're trying to save a hard-copy 1 of an order confirmation).

Almost no one has js disabled. Think about 9 coding your e-commerce website for the 70 8 year old woman who double clicks every link 7 and button. All you want to do is add a 6 javascript to prevent her clicking "Order 5 Now" twice. Yes - check this at the server 4 side too "be defensive" - but don't code 3 for that case. But for the sake of a better 2 UI do it on the client side too.

Here are 1 some scripts that I found:

//
// prevent double-click on submit
//
  jQuery('input[type=submit]').click(function(){
    if(jQuery.data(this, 'clicked')){
      return false;
    }
    else{
      jQuery.data(this, 'clicked', true);
      return true;
    }
  });

and

// Find ALL <form> tags on your page
$('form').submit(function(){
    // On submit disable its submit button
    $('input[type=submit]', this).attr('disabled', 'disabled');
});

None of the solutions address a load-balance 13 server.

If you have some load balancer, send 12 a UUID (or any type of unique number) to 11 the server to store and read again will 10 not work well if the server is not aware 9 of other servers, because each request could 8 be processed by a different server in a 7 stateless environment. These servers need 6 to read/write to the same place.

If you have 5 multiple servers you will need to have some 4 shared cache (like a Redis) among the servers 3 to read/write the unique value in the same 2 place (what could be an over-engineering 1 solution, but works).

Client side alteration is a common technique:

• Disable submit button
• Change the screen to a "please wait" screen
• If the form was modal, changing the screen back to their usual process (this has the benefit of making things look really slick)

But 7 it's not perfect. It all relies on JS being 6 available and if that's not the case, without 5 back-end duplication detection, you'll get 4 duplicates still.

So my advice is to develop 3 some sort of detection behind the scenes 2 and then improve your form to stop people with JS 1 being able to double-submit.

You can track the number of times the form's 3 been submitted and compare it to the number 2 of unique visits to the page with the form 1 on it in the session.

Beside the many good techniques already 4 mentioned, another simple server-side method, that 3 has the drawback of requiring a session, is 2 to have a session variable that is switched 1 off on the first submit.