Re^2: Preventing Duplicates

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

Comment on Re^2: Preventing Duplicates

Replies are listed 'Best First'.
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]

Replies are listed 'Best First'.

Re^3: Preventing Duplicates
by bart (Canon) on Mar 26, 2008 at 13:33 UTC

current values

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]