[nycphp-talk] Query result state strategy
Carlos A Hoyos
cahoyos at us.ibm.com
Wed Feb 15 17:58:46 EST 2006
> What about some sort of encrypted key stored in a hidden field on the
> client side? I could encrypt all the possible options and then cross
> check the submission against the encrypted value. I guess that's just
> shifting state info to the client -- is that safe if its encrypted?
You can pass a bunch of hidden variables and a hash of these variables with
a secret key to validate if they were tampered with. And if you do it
correctly, you can achieve some security with it.
This, btw, is used in simple integration schemas by some merchant gateways
to validate submitted information: You send your data (cc, amount, etc...)
and an md5 hash of the concatenation of all these variables and a secret
key. On their side, they calculate the hash again (only you and them can
know the key), and if it doesn't match, parameters were tampered.
Keep in mind most applications should be ok handling the query to the
database. Since you already need the database connection for the update,
and with a query cache, the overhead of the second query might be
negligible and your code might be much simpler.
More information about the talk