On 2002-10-29 10:05:01, Blake Frantz wrote:
> Using hidden fields is not a very good solution. The end user could
> simply construct their own html document and modify the hidden values to
> their liking.
Perhaps it was not clear that my hidden field's value was protected by
hmac (RFC 2104) Keyed-Hashing for Message Authentication, so hidden or
not was not really important.
> Have you considered separating the data into different tables? One with
> write permissions, one with read only?
I cannot.
> Or..
>
> Add a third column that indicates access levels required to modify that
> row. For example:
>
> Id txt access req.
> 1 bob user
> 2 sue admin
> 3 jon user
Yes, that would be (1) of my original message. I have no restriction
that only one user may change a given row, so it would have to be
implemented a little differently.
> Or..
>
> Add a third column that toggles the volatile state of the row. For
> example:
>
> Prior to serving end users with modification page
> Id txt volatile
> 1 bob 0
> 2 sue 0
> 3 jon 0
>
> After serving end user with modification page
> Id txt volatile
> 1 bob 1
> 2 sue 0
> 3 jon 1
>
> After modifications have been performed
> Id txt volatile
> 1 Bob 0
> 2 sue 0
> 3 Jon 0
Interesting, it's really a weaker implementation of (1) but if you have
one of these per session then it would work. E.g. session x may only
access the fields of these rows in these tables, it seems like a
non-trivial problem (e.g. sql fragments that you paste into to
update statement):
session fields rows
x tbl.txt id=1
x tbl2.txt fk=1
/Allan
--
Allan Wind
P.O. Box 2022
Woburn, MA 01888-0022
USA
- application/pgp-signature attachment: stored
Received on Oct 29 2002
Intro
