I think that Paweł meant action where you must show only data, without any user interaction (edit, delete and so on).
2010/12/21 Altenhof, David Aron <dalte...@iupui.edu>: > Yes ... loading in execute is exactly what I needed. Thanks! > > Is ViewAction a pattern, or is there an implementation? > > -David > > -----Original Message----- > From: Paweł Wielgus [mailto:poulw...@gmail.com] > Sent: Tuesday, December 21, 2010 5:09 AM > To: Struts Users Mailing List > Subject: Re: Parameter manipulation > > 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=newemai >>>>>> l >>>>>> @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 > > -- Maurizio Cucchiara --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
