> -----Original Message----- > From: Michal Mosiewicz [mailto:[EMAIL PROTECTED] > Sent: Saturday, September 20, 2003 4:15 AM > To: [EMAIL PROTECTED] > Subject: Re: [OS-webwork] formbean vs. action > > > >[...] > > > I'm not sure how possible that would be... Actually, I'm relatively > > certain that it would be difficult... It might be a feature > we could > > add with Xwork 1.1 when we rewrite the configuration API to > actually > > be runtime programmatically changeable... > > http://wiki.opensymphony.com/space/Xwork+Configuration > > It says that there is one instance of interceptor per action > and it can be parametrized in <interceptors /> and also > parameters can be added in action. Does that mean that it > doesn't work this way? Of course I understand that I cannot > apply parameters to stack elements, so that means that > parameter interceptor, to be configurable has to be defined > in every action and kept out of stacks.
It is possible to configure interceptors on an Action-by-Action basis... The difficulty is in configuring an Interceptor that's part of a stack. > > So, it is actually possible to configure separate interceptor > having it's own configuration, one per action, right? Yes > > Another question concerning potential validator usage to > solve security concerns. Does validation occur before > parameters are applied to action? Or does it rather check how > action has been parametrized? > It checks the Action property values. But it happens before your Action DOES anything (unless for some reason you have business logic execute during setXYZ() methods), so it should be perfectly safe. > As far as I can see validation is placed in stack after > ParameterInterceptor so I suspect that it works by checking > action properties, which is very weak. Why is this weak? > > Effectively validation can only prevent actions from being > executed, but there is a whole lots of damage that can be > caused by having actions to be configured even without > executing. Even if you could prevent balance to be written > down... what if someone notices some naming patterns on your > form, and finds out that your account object has interesting > 'owner' property which is so easy to populate with data by > sending ?account.owner.password='foo'. > So for the course of one request a transient object has an invalid value applied? And...? You're welcome to add more Interceptors, that's what they're there for, but I don't agree that the current Interceptors should change to handle these cases. > Of course that's just example that not necessarily happens. > The bottom line is that you have to be able to put a firewall > against input parameters before they get into action properties. > Again, why? > That's why I will advocate my idea, that filtering parameters > in ParameterInterceptor is not an option. It's a thing that > must me done. > Create another Interceptor to do this > I don't comment the idea of ProhibitedField pattern, cause > it's too weak to be sufficient. > I'm not sure I understand what the ProhibitedField pattern is, but how is it different from what you're talking about? > Another issue is OGNL usage. Potentially it's a very > versatile tool. But I can't measure the number of potential > holes that are open, when you use it to set parameters. Maybe > it could be used to bypass validator and execute action by > using carefully prepared parameters like 'this.execute()'. > Possibly.... We should look for a test case for this. > -- Mike > Jason > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Opensymphony-webwork mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork > ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
