Hitting submit twice

[pcwsp]

I have a set of scripts which work fine 99.5% of the time.

This is how they are supposed to work:

1. Customer completes order form and hits submit (once!)
2. Perl script contacts bank and waits for a reply
3. If the reply is negative, the script sends the error message to the customer's browser.
4. If the reply is positive, the script redirects the customer's browser to another script using Print location. This second script gives the customer access to whatever it is he has ordered.

The problems start if the customer hits the submit button twice. Then we have two instances of the same script running. This is what happens:

1. The first instance is waiting for a reply from the bank - sometimes this can take a while.
2. The second instance also contacts the bank, but because it has the same unique reference number, the bank immediately recognizes it as a duplicate and returns an error message, which goes to the customer's browser. So no double charge to credit card luckily.
3. In the meantime, the first instance has finally come back with a positive response, BUT it cannot get back to the customer's browser to give him access to his order. The Print location command fails and the script ends.

I would rather not rewrite the entire system for 0.5% of impatient customers, so I was wondering if there is way for the first successful instance of the script to tell if it has lost contact with the browser. Then it can maybe send an email with instructions how to access the order.

Would getting the script to detect the browser version be a possibility?

Any other suggestions?

Thanks.

[LanX]

not exactly a Perl question...

(Apart from JS) I'd try to solve this with a unique session ID in a hidden form field.

So repeated requests from the same form are blocked or cause a warning ("please wait")

This implies that the form is not static html, but generated by your script.

You can also combine this with a timestamp.

[Anonymous Monk]

Study the following things :) Proc::Background, Highlander: one instance at a time (Oct 00), Watching long processes through CGI (Aug 02) , Throttling your web server (Oct 00)

like the other guy said, disabling submit button, is quick and dirty way to "fix" it, but its mostly visual indication for impatient users (good GUI practice)

throttling/highlander is the real solution (button is just window dressing, important for user experience, but not controlling)

[Anonymous Monk]

I know this doesn't directly answer your question and won't cover 100% of your customers (those with JavaScript disabled) but it's a really easy to implement workaround: javascript disable submit button after click

[pcwsp]

Many thanks for the suggestions.

I don't think disabling the submit button under the current setup would work, because many customers make basic errors (eg. forget to enter email address etc) and need to resubmit. This basic error checking is done my the same script before sending the order to the bank. Maybe I need to find another way to check errors so I can disable the submit button.

And only allowing one instance of the program to run - what about other customers ordering simultaneously?

Atm I am leaning towards the hidden variable and having the form dynamically created by the program.

Thanks.

[Anonymous Monk]

I don't think disabling the submit button under the current setup would work, because many customers make basic errors (eg. forget to enter email address etc) and need to resubmit. This basic error checking is done my the same script ...

Disabling the submit button works entirely on the client side and has nothing to do with the server-side script - it really just prevents the submit button from being clicked twice in the browser. Also, re-enabling the submit button when necessary is just as easy as disabling it.

[Anonymous Monk]

Um, read all the articles, they each teach important basic techniques that complement each other and are your solution

[sundialsvc4]

The root cause of the problem is that the Submit from the Browser causes the web server, directly, to be the one that “queries the bank.”   And you become hosed either way, because the first process is still out there, still waiting to hear from the bank, and with no one left to send a reply back to because by then your impatient customer has reloaded his page.

Start by disabling the button, and giving the customer something to watch ... a progress bar works nicely.   See if that works.   Redesigning the application as-designed to suit, as you say, “a few impatient customers,” would be very undesirable.   Hope for the best.

[pcwsp]

Problem solved! Thanks to all those who suggested Java.

I disabled the submit button using onclick, and then enabled it again if the customer hits the back button to correct his mistake.

But once his order is correct enough to send to the bank, he is unable to hit submit again.

[Anonymous Monk]

Problem solved! ... he is unable to hit submit again.

That first part sounds great, the second has me confused: if the order is corrected, why shouldn't the customer be able to submit it then?

[pcwsp]

Sorry, I worded that badly.

I should have said "he is unable to hit submit twice".

Yes, after correcting his mistakes he is able to hit submit, and while the perl script goes off and contacts the bank, he is sitting there looking at a disabled submit button and a swirling progress graphic."