Arron wrote: > 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?... :)
The ActionForms ~are~ the buffering mechanism. That's one reason why they are not an interface. They should not be tied directly to a model, but serve as a pessimistic firewall betweeen the untrusted presentation layer (HTTP/HTML), and the rest of your application, which can then be more optimistic about the quality of data passed between components. What's happened is that when we added the nesting feature (late in the 1.0 cycle), we opened a backdoor that can realize some of the same problems caused when ActionForm was an interface. Someone can nest a bean that is tied directly to the model, and a hostile user can make unchecked system state changes. But, so long as the beans you nest do not update the system state (as the ActionServlet bean did), then there is nothing to worry about. A value object, for example, would generally be OK, since they accept data at one point, and then commit it at another. Between the accept and commit points, you can validate the input. But the ActionServlet exposed a direct setter, which is a bad thing on an ActionForm. So, we in affect, we wrapped it in a value object, so unauthorized system state changes could not be made. Nesting beans on an ActionForm is a powerful tool, but with power comes responsibility. The one and only danger is nesting a bean that makes direct changes to the system state via a public property which accepts a single String or boolean parameter. Protected or private properties or properties with complex signatures or types will not make it past the autopopulation guantlet. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel +1 716 737-3463 -- http://www.husted.com/struts/ > 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:[EMAIL PROTECTED]> > >For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
