NYCPHP Meetup

[Cliff Hirsch]

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

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?

Thoughts?

Hi Cliff,

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

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

Chris