> Is the preferred method of guarding against this sort of
> thing to create a UUID with every record and do a check
> of that when allowing db actions against the record?
>
> Any better (ie easier or less time consuming) methods to
> this?
I'm not sure what you're trying to accomplish, exactly.
For the client to be able to do anything, you're going to have to accept
certain input values from the client. In HTTP, the client can see and
manipulate these input values directly, instead of using the HTML interface
you provide, so you have to ensure that they're valid and acceptable. But
that's really all you can (and need to) do.
So, if you want the client to be able to do something with a record, you'd
need to have the client provide some input value to let you know that this
specific client has the authorization to do the appropriate action.
Typically, people do this by providing an authentication and authorization
process, such as CFLOGIN, which allows your application to log in a user and
determine what roles that user has. Assuming that the authentication token
(the CFLOGIN cookie, CFID & CFTOKEN or JSESSION identifiers) is very
difficult to guess or brute force, you shouldn't have to do anything else.
Dave Watts, CTO, Fig Leaf Software
http://www.figleaf.com/
voice: (202) 797-5496
fax: (202) 797-5444
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
