On Tue, 2006-05-23 at 15:01, Paul Novitski wrote:
> At 11:08 AM 5/23/2006, Lester Caine wrote:
> >I could not believe that double clicking a link would run the link
> >twice. It just does not make any sense. So I've been round the
> >browsers. IE does NOT process the link twice how ever I try and
> >since all the user sites are IE they should be OK.
> >Moz, Firefox and Sea Monkey *DO* run the link twice, and any code
> >attached to that link.
> >I can't believe that this has not surfaced before. I should not need
> >to prevent duplicate actions, but it looks as that is required by
> >the Mozilla browsers :(
>
>
> Just to clarify, there's a difference between "double-clicking" and
> clicking more than once before the form completely submits.
>
> Double-clicking is a GUI event, the two mouse clicks bound together
> as a single event as defined by your mouse properties in your
> computer's operating system.
>
> It is certainly possible to single-click once to submit a form, then
> single-click again to submit the same form a second time before the
> first request has completed. This sends two submissions to the
> server and is a common problem on pages that have left this door wide open.
>
> Before I wandered off into the dense jungle of possible browser bugs,
> I'd make absolutely sure my users can't submit the form more than once.
>
> There is no way you can prevent your users from clicking more than
> once unless you visit them and physically restrain them, a strategy
> which would quickly exhaust your resources and soon curtail your
> personal freedom. Instead, you have to assume that some of your
> users WILL multiply click (whether deliberately or accidentally) and
> plan for that contingency. Multiple submissions can happen for a
> variety of reasons:
> - maliciousness;
> - accidentally clicking twice (happens to me when I've been working
> too long: my mouse button finger sometimes just clicks of its own accord);
> - getting impatient with a form submission that takes more than a few
> seconds and either clicking again or reloading the form to try again.
>
> A client-side solution is for Javascript to disable the submit button
> onsubmit(), however this wouldn't prevent the user from reloading the
> page and submitting a second time and wouldn't work at all if
> scripting were disabled.
>
> A server-side (and therefore more robust) solution is to accept only
> one form submission from each user/session.
>
> An additional strategy to make your system more robust is to use
> three pages for your form submission:
>
> 1) the form itself, which submits to:
> 2) the script that processes input, which redirects to:
> 3) the page that displays the results (or is the next form in a sequence).
>
> Even if the user reloads the results page (3) they won't be
> resubmitting the form (1) or repeating the input processing (2).
I think a 2 page scenario is simpler and more elegant:
1) the form itself, which submits to itself for validation
and re-presenation in case of validation errors
(including multiple submission of same form - such as
going back in browser). This also means if errors occur
then the form can be presented with previously
submitted data.
2) the final destination page(s) after the form has been
submitted with successful validation to which the user
is redirected (preventing reload submissions).
Cheers,
Rob.
--
.------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`------------------------------------------------------------'
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
