Hello Arron, I think that it is intersting and flexible approach. Can you supply samples for it or refactor existing code to support such ideas?
Wednesday, November 28, 2001, 6:37:06 AM, you wrote: AB> Not a special class, I'm talking about placing it into the process. AB> Before the servlet updates the properties it checks for a security AB> mapping. Based on the request and the security, it updates the AB> properties. It would be more secure, and every property which is up to AB> be set, can rest assured that it's safe. And that includes the AB> properties that we "mean to expose" nested or otherwise. AB> All amounting to better security and an easier development path for the AB> developers. AB> I've had to use a decoupling through nested objects for an app that's in AB> development. 100's of input fields. Writing proxy classes for it all. AB> You have to be kidding. AB> Ted, there are some requirements out there where you *must* use nested AB> objects. AB> When is Struts going to *properly* support this!!??... AB> Arron. AB> 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. >> >>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]> >> AB> -- AB> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> AB> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- Best regards, Oleg mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
