Hello Mark,

The most reliable "double click" prevention that I can think of (that is fairly simple to implement) and is server-side oriented is to send a Unique GUID with every form, store each one in an Array in the Session variable (an array in case there are potentially more than one form active at a time - not likely - but...).

Then - when a form is submitted, check to see if the GUID is currently valid.  If it is, you can continue processing and you immediately remove it from your Array.  If it is not there, then it is invalid and you can tell them to stop pressing the button.

Of course, there is always the chance that they will press it again before you have cleared the entry in the Array but - that's client/server for you.  Fortunately, most uses DO wait a little while before clicking again - by then you will have cleared out the GUID for the form.  This does not stop them going back to the original form, getting a new GUID, and sending that - but that really is a different request and you have to handle that by checking to see if you already have a response from them (via IP or login id, etc).

The other advantage of this method is that you can then also stop auto posters from blatting your site with dummy forms (because if the form comes from you it will have a currently valid GUID sent over).  They can send a GUID field (if they like) but you will not have a current valid value for it.


Gary Menzel
IT Operations Brisbane -+- ABN AMRO Morgans Limited
Level 29, 123 Eagle Street BRISBANE QLD 4000
PH: 07 333 44 828  FX:  07 3834 0828


[EMAIL PROTECTED] wrote on 03/27/2003 11:36:02 AM:

> Hey All
>
> I've got a site that has some users who are on very slow connections. These
> users have the tendency to click a submit button, wait, click again, wait,
> click, click, click - just in case the computer has had trouble
> understanding that they clicked the first time.
>
> I am aware that you can do various js work arounds to prevent subsequent
> clicks from having any action, but this is kind of messy for all the usual
> client side reasons. I am also - wherever possible - checking in my code to
> see whether the current action is a duplicate:
>
> query to check if record already exists
>    if not
>       do some things
>       do some more things
>       do lots more things
>       write record
>
> However I've still occasionally getting duplicates> I guess they are coming
> from the first test being performed on the duplicate before the record is
> written for the first item. (home this is making sense)
>
> My question is can you use <cflock type="exclusive"> to lock this code block
> and two processes running this same code at the same time? I.e. request 2
> waits for request 1 to completely finish before bringing its processing.
>
> I guess I could alternatively put my test immediately before updating the
> database:
>
> do some things
> do some more things
> do lots more things
> query to check if record already exists
>    if not
>       write record
>
> Thanks in advance
>
>
> Mark
>
>
> ______________
> Mark Stanton
> Web Production
> Gruden Pty Ltd
> Tel: 9956 6388
> Mob: 0410 458 201
> Fax: 9956 8433
> www.gruden.com
>
>
>
> ---
> You are currently subscribed to cfaussie as: [EMAIL PROTECTED]
> To unsubscribe send a blank email to [EMAIL PROTECTED]
>
> MX Downunder AsiaPac DevCon - http://mxdu.com/
****************************************************************************
If this communication is not intended for you and you are not an authorised
recipient of this email you are prohibited by law from dealing with or
relying on the email or any file attachments. This prohibition includes
reading, printing, copying, re-transmitting, disseminating, storing or in
any other way dealing or acting in reliance on the information. If you
have received this email in error, we request you contact ABN AMRO Morgans
Limited immediately by returning the email to [EMAIL PROTECTED]
and destroy the original. We will refund any reasonable costs associated
with notifying ABN AMRO Morgans. This email is confidential and may contain
privileged client information. ABN AMRO Morgans has taken reasonable steps
to ensure the accuracy and integrity of all its communications, including
electronic communications, but accepts no liability for materials
transmitted. Materials may also be transmitted without the knowledge of ABN
AMRO Morgans. ABN AMRO Morgans Limited its directors and employees do not
accept liability for the results of any actions taken or not on the basis
of the information in this report. ABN AMRO Morgans Limited and its
associates hold or may hold securities in the companies/trusts mentioned
herein. Any recommendation is made on the basis of our research of the
investment and may not suit the specific requirements of clients.
Assessments of suitability to an individual's portfolio can only be made
after an examination of the particular client's investments, financial
circumstances and requirements.
****************************************************************************
--- You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] MX Downunder AsiaPac DevCon - http://mxdu.com/

Reply via email to