The issue is that some properties on an arbitrary object might be OK to populate from the request, and others might not be. The securityissue is that it's not only the properties on the object itself, but properties on objects that the object might reference.
As Martin mentioned, once upon a time, you could acquire a reference to the ActionServlet from the ActionForm. This meant you could (through the dotted syntax) set any property on the ActionServlet. If the ActionServlet returned any objects, you could also set properties on those objects. Yes, the VO would be setting the contract, but many developers would not realize how much fine print might be in that contract :) Meanwhile, FormDef [https://formdef.dev.java.net/] is an interesting extension that does this sort of thing, but uses a "dynamic" DynaActionForm as a go-between. -Ted. On Wed, 16 Mar 2005 15:53:35 -0600, Michael Rasmussen <[EMAIL PROTECTED]> wrote: > > > > I understand what you're suggesting, and on the face of it, it seems > > like a nice idea. However, I fear that including such a mechanism in > > Struts would lead to serious security vulnerabilities in some peoples' > > applications. This is because essentially *any* method on the POJO > > could end up being invoked accidentally or maliciously. We had an > > Isn't that only true if the form is getting its contract from the html > form rather than the VO? > > I am assuming the vulnerability is that someone could add a parameter > to their request url and inject the value into the form arbitrarily > calling a public "logMeIn()" method. > > If however you were to create the contract from the VO, the logMeIn > parameter will just be ignored. Is that incorrect? I'm asking > because I'm curious about the issue. > > > > issue like this with ActionForm some time ago, until someone pointed > > it out to us. > > > > -- > > Martin Cooper > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- HTH, Ted. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
