On Tue, 2003-10-28 at 14:18, Justin Ruthenbeck wrote:
> At 04:20 PM 10/27/2003, you wrote:
> >On Tue, 2003-10-28 at 12:51, Justin Ruthenbeck wrote:
> >
> > > Server side, instead of putting a token in the session when the page
> > is
> > > *served*, put a token in the session while the submission is being
> > > processed (use it like a semaphore). The token has a finite lifecycle
> > > (created on form submission, death on submission response
> > > served).
> >
> >This only works if processing the two submissions overlaps. If the logic
> >to process the submission is very fast, or there is a long delay between
> >submissions, then this won't work.
>
> <from original post>
> I've designed my workflows so that they do not need to store anything in
> the user's session. This allows the user to conduct more than one
> instance of a particular task at the same time without data getting
> mixed up. However this presents me with a problem if the user double
> clicks the submit button and causes the server to do something twice.
> </from original post>
>
> If the logic to process the submission is very fast, then presumably your
> client would have a response before clicking the submit button again. If
> there is a long delay between submissions, then you're dealing with an
> entirely different problem -- ie not "user double clicks the submit
> button."
While the logic on the server is reasonably fast, we can't be sure that the network latency is so low that the user can't double click, nor that the server will always be fast all the time. In fact we have several cases of this actually happening and two records being created on the server.
Alright, we're starting to go around in circles.
Here's the situation (correct me if I'm wrong): + User fills out a form and clicks submit + The browser submits the form and sits in a wait state + The server begins processing a request for a new record + The user clicks submit once again + The browser submits the form and sits in a wait state again + The server begins processing a second (identical) request
This is classic double submission where two requests for the same thing overlap on the server. Your server thinks they are independent, but you only want one to complete since it's actually a user error.
In this situation, either of the original 2 suggestions (client or server side) should work. Add client side js code that only allows the user to click a button once. To back it up (don't rely on the client to behave), only allow one submission of that particular form at a time. Make sure the form does not get cached. The only way a client will get around this is to have two separate copies of the form and submit both of them -- presumably this would mean they *intend* to have two copies.
This takes care of accidental double clicking. If you absolutely must guarantee that the form is only submitted once, then you have no choice but to create a UID for the form and match it before allowing the submission, in one way or another.
And if you're concerned about this affecting your long term memory performance, there are ways to mitigate the impact ... you almost surely don't need this level of guantees for every request.
Let me know if I'm not understanding what you're trying to get at ... doesn't sound like your requirements are any different than general double-click defenses, though.
Cheers,
justin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
