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

Reply via email to