Re: Preventing Duplicates

You're not the only one having this problem: even Perlmonks suffers from it.

Basically I see 2 main approaches to prevent it:

Add some form id to your form, which can be used only once. It may be just a counter value, or a random number, but you must make sure it's never used again. If your system notices a repost, thus, a form id that is used more than once in a submit, it should either reject the data, or update the data that got inserted before.
Do not show your results in the same page that received and processed the data. In other words: redirect. The page that recieves the data then inserts it, and next jumps to another URL which only shows the data, and which is safe to reload. The main problem I see here is passing the status messages to the next page. Preferably, IMO, they should disappear after a reload.

Oracle appears to use yet another mechanism in their Web-PL/SQL system (as generated by Oracle Designer), in particular for updates: they add the previous values for record fields as hidden form variables, and check if these values are still the current values at the moment of the update. If not, it'll complain and refuse to do the update. That way, you cannot overwrite other people's changes by accident. Not a bad idea, IMO. (What I do find a bit odd is the name they give to this mechanism: "record locking".)

Comment on Re: Preventing Duplicates

Replies are listed 'Best First'.
Re^2: Preventing Duplicates by andreas1234567 (Vicar) on Mar 26, 2008 at 13:21 UTC
they add the previous values for record fields as hidden form variables, and check if these values are still the current values at the moment of the update. Unless combined with both encryption and digital signatures, I'd say it would generally be a security risk to pass data to the browser and rely on that they come back unaltered. Don't hide sensitive information in hidden form fields, (searchsecurity.techtarget.com). Update: Re-phrased "it is" to "it would generally be". -- Andreas	[reply]
Re^3: Preventing Duplicates by bart (Canon) on Mar 26, 2008 at 13:33 UTC
You may alter them all you like, after all, those are the values that you are allowed to edit. But, unless the hidden values are identical with the current values for those fields in the database, the update will not happen. That means that, for the update to take place, that either you have to not touch the hidden values at all, or, if the record got updated in the meantime, you must know exactly what you're doing, and manually fill in the new exact current value for those fields. I agree that it's a bit of an overkill, especially for long strings, to send the same data to the browser more than once. After all, just sending a CRC or digest value (MD5, SHA1,...) would suffice, for the check.	[reply]