struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arron <>
Subject Re: Extensibility of struts & Property Security
Date Wed, 28 Nov 2001 14:22:51 GMT
>This idea came up in the original thread, but no one stepped forward
>with any code. 
It has my interest.
I'll first take a squizz at the target areas, generate a hack version, 
look at the viability, and see what happens from there.

>The one and only time there is a problem is when the nested object makes
>a direct and immediate change to the internal system state. So long as
>the nested object is buffering the input, and can be validated before
>any change is committed, then it's a non-issue.
How does the current buffering mechanism do its thing for flat beans?...
Is there a short answer without telling me to go read the code?... :)


>Arron Bates wrote:
>>Not a special class, I'm talking about placing it into the process.
>>Before the servlet updates the properties it checks for a security
>>mapping. Based on the request and the security, it updates the
>>properties. It would be more secure, and every property which is up to
>>be set, can rest assured that it's safe. And that includes the
>>properties that we "mean to expose" nested or otherwise.
>>All amounting to better security and an easier development path for the
>>I've had to use a decoupling through nested objects for an app that's in
>>development. 100's of input fields. Writing proxy classes for it all.
>>You have to be kidding.
>>Ted, there are some requirements out there where you *must* use nested
>>When is Struts going to *properly* support this!!??...
>>Ted Husted wrote:
>>>Personally, I have the feeling that it's better to encourage people to
>>>define a proxy object, or wrapper, as was done with the ActionServlet,
>>>than invent a special class for people to learn.
>>>I actually believe that this is the approach that should have been used
>>>in the first place, and in other places in the codebase. The
>>>ActionServlet was placed there to provide access to certain properties,
>>>and now the wrapper object defines exactly which properties those are.
>>>An Encapsulate Class refactoring, if you will.
>>>Meanwhile, I'm suggesting that we do the same sort of thing with
>>>multiple ActionSerlvets in another thread. Instead of exposing the
>>>ActionServlet, we should expose a JavaBean with only the properites we
>>>mean to expose.
>>>I think the important thing is to pound on the point that the ActionForm
>>>is a firewall; it, and any objects it nests, are in the wild.
>To unsubscribe, e-mail:   <>
>For additional commands, e-mail: <>

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message