struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arron <ar...@keyboardmonkey.com>
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.

>
>
>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
>>developers.
>>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
>>objects.
>>When is Struts going to *properly* support this!!??...
>>
>>Arron.
>>
>>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:   <mailto:struts-dev-unsubscribe@jakarta.apache.org>
>For additional commands, e-mail: <mailto:struts-dev-help@jakarta.apache.org>
>



--
To unsubscribe, e-mail:   <mailto:struts-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-dev-help@jakarta.apache.org>


Mime
View raw message