So, I currently work around this issue by validating server-side that
the user has the appropriate permissions to edit the object[s] that
came back with the request. However, I[ve been thinking for awhile
now of extending my existing squeeze adapter implementation (the one
on Tassel) to address security concerns like this. One possibility
would be to use some sort of hashing mechanism, as mentioned by
Peter. Another possibility (which is something I'm leaning towards)
is to allow for some sort of "security manager", where the squeeze
adapter can "re-inflate" the object, then hand it off to the security
manager for inspection to make sure that the user responsible for the
current request has permission to access the object. Thoughts/comments?
Robert
On Apr 12, 2007, at 4/128:23 AM , Michael Gentry wrote:
> Just a note (yes, this is one of my soapboxes and Steve and I
> discussed this
> ages ago): If you need data security in your application, don't use
> the data
> squeezers with Tapestry. The squeezers are great if you don't care
> about
> security, but if you do, they are too problematic for someone who
> wants to
> try hacking things. They encode primary keys to your data objects,
> which
> can be altered by someone before being sent back to you, causing
> (potentially) incorrect records being retrieved/updated. (At least
> the last
> time I looked at it...)
>
> The above isn't meant to detract from Steve's tutorial, either,
> which is
> great and we are the better for having it available.
>
> Thanks!
>
> /dev/mrg
>
>
> On 4/12/07, Peter Schröder <Peter.Schroede..reenet-ag.de> wrote:
>>
>> it was a perfect tutorial to my work on a new job. it was exactly
>> what we
>> are now using here as development-environment.
>>
This archive was generated by hypermail 2.0.0 : Thu Apr 12 2007 - 12:12:42 EDT