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. Arron Bates wrote: > > Yes, yes. Point made. > That series of emails makes for some good bedside reading. > > I think that the solution that was arrived at is fine for protecting the > struts system objects themselves. > Is there anything happening to allow the developer to protect their own > properties from this kind of arbitrary attack? > > Thought I had would be to configure a property modifier, or property > mapping which yields other "security properties" which have to be > checked before a property is set. ie: getMyProperty() property method > uses a getMyPropertySecurity() to return a defined value which was set > while writing the view so you can't just pass the one key value pair to > change a value, but a two key value pairs with the second value being a > specific hashing or such. This would stop the casual hacking of any > property via the URL. You could also then define a security property for > all things struts within the ActionForm. > > The possibility then in extending this would be to define a security > property to each property to be set, or a more simpler global security > property for the entire request, and let the developer decide as to how > fine grained the property setting security should be, if at all. > > Just a thought. > > Arron. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
