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).
I thought the first one might have problems, and this one I picked up on. A replace-into won't work either, because it would allow the created record to be replaced with another.
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.
I do that, the user ID is required to be unique, but a replace into would allow the record to be overwritten with a new ID.
I'm using an index record (auto inc, 1,2,3...) to tie the various records together, but the user ID is random.
I don't want someone to come in and duplicate the signup info and cause their user id to become inactive.
The refresh-resubmit would cause all the fields (except the ID) to be identical though, so I'm implementing a scan for that. If you submit identical data, then you'll get a message that "your information has already been processed", and it won't create another record.
The fun part is that in the current system, submitting this form also sends two emails, one to the email you submit (dvanhorn@cedar.net in my case) and another to the root account at that domain (root@cedar.net) The root email contains a passcode that is needed to authenticate the user. This way I can be pretty sure that they have the authority to act for the domain. I figure if they have access to the email of root@domain.com, then they are authorized.
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
--
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
--
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