Maybe if the OP moves the bean creation out of the prepare() method (so the bean isn't available during parameter injection) and then retrieves it at the start of validate() or execute() that might solve the problem. (*Chris*)
On Fri, Dec 17, 2010 at 10:05 AM, Chris Pratt <thechrispr...@gmail.com>wrote: > If the bean already exists, struts doesn't have to set it. It just has to > modify the retrieved bean. > (*Chris*) > > > On Fri, Dec 17, 2010 at 9:48 AM, <stanl...@gmail.com> wrote: > >> I agree S2 will create the bean (if null) but it can't set a property that >> is private and has no accessible setter method. >> >> P.S. What am I missing here? >> >> Scott >> >> On Fri, Dec 17, 2010 at 11:45 AM, Maurizio Cucchiara < >> maurizio.cucchi...@gmail.com> wrote: >> >> > This happens because bean is null, otherwise struts will populate. >> > >> > 2010/12/17 <stanl...@gmail.com>: >> > > Guys -- >> > > >> > > If the action has no setter and the property is private, S2 will not >> > > populate it. >> > > >> > > Scott >> > > >> > > On Fri, Dec 17, 2010 at 11:10 AM, Maurizio Cucchiara < >> > > maurizio.cucchi...@gmail.com> wrote: >> > > >> > >> David, >> > >> I get your point. >> > >> >> > >> Scott is right, you could overwrite PI or maybe write your custom >> > >> interceptor (though I think you should consider to file an issue on >> > >> JIRA). >> > >> Maybe it would use java annotations to hide/expose fields, or >> > >> alternately it could behave as you supposed (expose only field with >> > >> write accessors). >> > >> >> > >> >> > >> >> > >> >> > >> 2010/12/17 Altenhof, David Aron <dalte...@iupui.edu>: >> > >> > The model objects are initialized in prepare() ... other techniques >> > just >> > >> aren't as practical for our application. >> > >> > >> > >> > I'm just going to keep doing lots of whitelisting with >> > >> ParameterNameAware... >> > >> > >> > >> > -David >> > >> > >> > >> > >> > >> > >> > >> > -----Original Message----- >> > >> > From: Steven Yang [mailto:kenshin...@gmail.com] >> > >> > Sent: Friday, December 17, 2010 1:10 AM >> > >> > To: Struts Users Mailing List >> > >> > Subject: Re: Parameter manipulation >> > >> > >> > >> > is your user object initialized when the param interceptor is run? >> > >> > >> > >> > here i might be wrong, but what i know is if your object is >> > initialized >> > >> then Struts or OGNL will call getUser().setEmail(...) otherwise >> create a >> > new >> > >> User then setEmail then setUser then the second case should fail for >> you >> > >> > >> > >> > again, i might be wrong on the behavior >> > >> > >> > >> > On Thu, Dec 16, 2010 at 12:39 AM, Altenhof, David Aron >> > >> > <dalte...@iupui.edu>wrote: >> > >> > >> > >> >> I've been getting more and more concerned about the possibility of >> > >> >> parameter manipulation attacks with Struts2. I've started doing >> > strict >> > >> >> whitelists using the ParameterNameAware interface on all of my >> forms >> > >> pages. >> > >> >> However, today I tried to code a "display-only" page that shows >> > >> >> information about a particular user. I thought that by simply >> > creating >> > >> >> a getter and no setter, it would be impossible to inject >> parameters. >> > >> >> For example, my action only contains the following getter for a >> JPA >> > >> model object: >> > >> >> >> > >> >> public User getUser() { >> > >> >> return user; >> > >> >> } >> > >> >> >> > >> >> However, by sending a simple query parameter, it is *still* >> possible >> > >> >> to change values in user. For example, you can send: >> > >> >> >> > >> >> >> > >> >> >> > http://localhost:8080/MySite/userdisplay.action?user.email=newem...@ad >> > >> >> dress.com >> > >> >> >> > >> >> ... and it works. The email will become newem...@address.com >> > >> >> >> > >> >> Is there any way to shut this down other than whitelisting every >> > >> >> single action in your site using ParameterNameAware? (Or simply >> never >> > >> >> put model objects on your stack?) This is getting frustrating! >> > >> >> >> > >> >> -David >> > >> >> >> > >> >> >> > >> >> >> --------------------------------------------------------------------- >> > >> >> To unsubscribe, e-mail: user-unsubscr...@struts.apache.org >> > >> >> For additional commands, e-mail: user-h...@struts.apache.org >> > >> >> >> > >> >> >> > >> > >> > >> > >> --------------------------------------------------------------------- >> > >> > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org >> > >> > For additional commands, e-mail: user-h...@struts.apache.org >> > >> > >> > >> > >> > >> >> > >> >> > >> >> > >> -- >> > >> Maurizio Cucchiara >> > >> >> > >> --------------------------------------------------------------------- >> > >> To unsubscribe, e-mail: user-unsubscr...@struts.apache.org >> > >> For additional commands, e-mail: user-h...@struts.apache.org >> > >> >> > >> >> > > >> > >> > >> > >> > -- >> > Maurizio Cucchiara >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org >> > For additional commands, e-mail: user-h...@struts.apache.org >> > >> > >> > >
