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