[nycphp-talk] Query result state strategy
cliff at pinestream.com
Wed Feb 15 14:19:14 EST 2006
Thanks for the reply Chris -- see, I've become a believer...
Ok, so here's one case:
I display a bunch of rows. Each row has several fields, including a few
status fields (some displayed, some not).
Various actions (buttons) are allowed based on combinations of the
status fields. (As a side-note, this relates to the state table thread I
started last week). I disable buttons that are not allowed, so only
valid actions can be submitted, but it would be trivial to submit a
button that has been disabled.
When I receive a button submission for a particular row, I query the row
from the db, and check to see if this action is allowed based upon the
If it were as simple as checking for a userid, I could do a single step
update on the row using something like WHERE row = submittedrowid and
userid = guyloggedin. In fact, I will probably double check the logic
flow to see if the validation and DB update can be compressed into a
single query. Like "UPDATE SET price = price + submission WHERE fields
meet conditions" Failed update == failed validation, or something like
that. But the button actions are based on a complex set of status codes
and launch a flurry of processes. So this scenario might not work.
Stream of consciousness going here... As I think about this, it seems
like I can still only compress a DB read and write to a single update --
with a lot of work.
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?
Cliff Hirsch wrote:
> Lately, it seems like I need to execute queries twice -- the first
> time to gather data and set actions for the presentation layer. That's
> What disturbs me is that I need to do this all over again when
> receiving actionable input, going along with the theory that all input
> from the client is evil unless proved otherwise. Thank you Chris.
You're welcome? :-)
Can you give us a more concrete example? It seems likely that you can
avoid having to query the database multiple times just to be able to
maintain a healthy level of suspicion.
More information about the talk