So, in case of the OP, are you suggesting to remove setter method from User's email?
2010/12/17 <stanl...@gmail.com>: > 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 >> >> > -- Maurizio Cucchiara --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org