JSF 1.2 handles issues like this by encrypting the state sent to the
client. Don't know if that's appropriate or any better than using a
secret key and a hash.
On 4/12/07, Robert Zeigler <robert..uregumption.com> wrote:
> 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:15:01 EDT