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 <[EMAIL PROTECTED]> 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.
