Re: Refresh-avoidance
| From: | Thomas Reinke | Date: | Wed, 28 Jun 2000 13:07:56 +0000 |
| Subject: | Re: Refresh-avoidance | ||
| References: | 1 | Groups: | php.general |
| Request: | Send a blank email to php-general+get-3546@lists.php.net to get a copy of this message | ||
Of the responses you've received Dave, there are a lot of problems
that you should be aware of.
1) The suggestion of a page processing the transaction,and then
using redirection to move to a final "Thank-you page" does
not work, so don't try it. In this type of scenario, if you
do a reload on the browser while on the thank-you page, it
knows enough to skip the intermediate redirect page, and will
attempt to resubmit the form from the original page.
2) All the db suggestions that tell you to do a check first, or
a replace into, are valid if and only if you can do a db lock
(e.g. a "BEGIN" transaction statement) to ensure the database
isn't being changed half-way through (ala user submitting
twice in rapid succession, and having two PHP scripts concurrently
trying to add the exact same user).
The best solution to this problem IS at the database end. But the
trick is to make use of what is known as an atomic transaction that
will do what you need. For example, if your userids must be unique
in the database, then use the database to create a unique primary
key index on this userid. This means that when you add a record
into the database, the database will automatically reject it if
the userid already existed, and you can then handle the response
appropriately. Note...you don't do a "scan" and then "insert",
you just plainly issue the insert, and rely on the db to reject
duplicates.
By doing the above, you've created a solution that not only solves
the reload problem, but ALSO address different users happening to
pick the same userid.
Thomas
David VanHorn wrote:
>
> I have a form issue that's bugging me.
> As a part of a user signup, there is a page with a form.
> The user fills out the form and submits, and all is well, and he gets a
> confirmation screen, but if he refreshes the confirmation screen (this page
> contains the script that does the signup work) then a duplicate account is
> created.
>
> I know I can scan for dupes and abort, but is there a simpler way to avoid
> this?
> (Like a "refresh-killer"?)
>
> TIA
> --
>
> www.SpamWhack.com A pre-emptive strike against spam
> A tornado is a lady whose skirts you do NOT want to look up!
> Where's dave?
> http://www.findu.com/cgi-bin/find.cgi?kc6ete-9
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, e-mail: php-general-unsubscribe@lists.php.net
> For additional commands, e-mail: php-general-help@lists.php.net
> To contact the list administrators, e-mail: php-list-admin@lists.php.net
--
------------------------------------------------------------
Thomas Reinke Tel: (905) 331-2260
Director of Technology Fax: (905) 331-2504
E-Soft Inc. http://www.e-softinc.com
Publishers of SecuritySpace http://www.securityspace.com