Hello Arron, Ideas... Great. I think that source code samples can be more useful than abstract ideas in free style. Every developer in this list has his own work and doing struts-related activity by his free time. If you can help in this way to the community, please post code and config samples to the list.
Wednesday, November 28, 2001, 5:22:45 PM, you wrote: A> No code, just an idea after Ted provided a link to a thread of mails A> that had to do with the original problem of getting at the struts system A> objects. A> But I'm lookin into it. A> I'll get back to ya, but should be able to get a mock set-up running of A> the idea itself... A> ...then the debate can start as to the syntax of configuring it, and A> when, should it be a singleton, ad-infinitum. :) A> Arron A> Oleg V Alexeev wrote: >>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]> >> >> >> A> -- A> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> A> 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]>
