>[...] > 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. So, it is actually possible to configure separate interceptor having it's own configuration, one per action, right? 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? 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. 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'. 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. 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. I don't comment the idea of ProhibitedField pattern, cause it's too weak to be sufficient. 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()'. -- Mike ------------------------------------------------------- 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
