Hi All,
adding just one note to what Marcus already said,
will You be able to update your whitelist every time User class (or
any other viewable) gains new field?
And again *ViewAction is for view only - it should be technically
impossible to change viewed object state.
One simple way to do it is loading this object in execute method.

Best greetings,
Paweł Wielgus.


2010/12/18 Marcus Bond <mar...@marcusbond.me.uk>:
> David, didn't your original post say that this is an action that loads an
> object to display it rather than to modify it? In which case I'm not sure
> why you even need to use Preparable (as I'm guessing it's during prepare
> that the instance is initialised which makes it available for struts to
> populate during the second params setting). At a guess you're setting an id
> in the initial params phase which then is used to load the instance? Why not
> just load it during execute (or whatever other method is being called by the
> action mapping) so it isn't there for any params to be applied earlier?
>
> Regards,
> Marcus
>
> On 17/12/2010 20:02, Altenhof, David Aron wrote:
>>
>> One approach I've through of is to create an interceptor that would parse
>> through your -validation.xml (assuming one uses them) and then only allow
>> parameters that have an associated validator. This would actually serve two
>> goals: 1) Preventing parameter fiddling 2) Mandating the wise practice of
>> validating all incoming data.
>>
>> Now if I could only find a few spare cycles to work on it...
>>
>> -David
>>
>> -----Original Message-----
>> From: Chris Pratt [mailto:thechrispr...@gmail.com]
>> Sent: Friday, December 17, 2010 1:08 PM
>> To: Struts Users Mailing List
>> Subject: Re: Parameter manipulation
>>
>> 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=newemail
>>>>> @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
>>>>>
>>>>>
>>>
>> ---------------------------------------------------------------------
>> 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
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org

Reply via email to