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
>
>

Reply via email to