NYCPHP Meetup

[Cliff Hirsch]

Carlos:

Sounds like an interesting approach. I like it for scaling out.

But you make an interesting point regarding the second query -- caching
could reduce the load significantly. And regarding simplicity, I've been
leaning more and more towards just getting the application finished and
worrying about performance later. I hate to admit that, but planning for
a hundred million users seems senseless if the application is never
finished.

> 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.

Carlos