|
|
Posted by Gordon Burditt on 03/11/07 22:22
>ok, sorry for the top posting, by "top posting" you mean writing your
>reply at the top, right? back to the question - i don't want to give
>the user an opportunity to monkey around with the html somehow, and
Using CURL is much easier than monkeying around with HTML, and you
can't stop it.
>send back a bogus response via a POST variable.
>I want to ensure 2
>things- first, that the person is authorized to edit this row, and
Then when the user submits his edit of the row, you CHECK that he
is authorized to edit that row *WHEN HE SUBMITS IT*. This is not
the same thing as checking what the user is authorized to edit when
he pulls up a screen of records he might edit, or checking when he
starts the edit (although those are a good idea ALSO). Why? Between
those times, the user might have had his account cancelled, or he
might not own the record any more, or he's changed jobs so he doesn't
have the authority to edit records any more, or whatever.
>second, that this is the row that he or she is authorized to edit. It
>sounds like sessions are the way to go with some kind of encyrption.
>Is that the generally accepted way of doing this?
Data in sessions is not sent to the browser nor accepted back from
it, so the user cannot directly tinker with it. It's good for
keeping track, for example, of who if anyone is logged in for this
session. But editing inherently involves getting input from the
user. Check that he has the authority AT THE TIME YOU'RE MAKING
THE CHANGES, as well as earlier. The editing process will probably
involve several checks that the user has the authority to edit: don't
skimp on these.
Navigation:
[Reply to this message]
|