One more side note, if i understand it wright, in my case (Edit input and execute methods) wildcard mapping would be better from framework perspective but it needs to be wriitten in xml configuration.
Whereas DMI do not require me to write any xml, but is not first class citizen in terms of framework. Best greetings, Paweł Wielgus. 2013/9/24 Paweł Wielgus <poulw...@gmail.com>: > Hi Lukasz, > i see no problem for me in solution described by You. > Off course i'm no security expert here. > > Best greetings, > Paweł Wielgus. > > > 2013/9/23 Lukasz Lenart <lukaszlen...@apache.org>: >> 2013/9/23 Paweł Wielgus <poulw...@gmail.com>: >>> Hi all, >>> I'm using DMI to call "input" method extensively, >>> almost in every Edit*Action. >>> I call it with ParamsPrepareParams stack. >>> >>> I fully understand that allowing DMI is a security problem. >>> But maybe some kind of balance could be achevied. >>> White listing with annotations would not be bad for me >>> also maybe letting call only input (or similar) method by default >>> would not cause to much of a security problem? >>> >>> I'm not saying that i will drop S2 >>> if DMI will be disabled, >>> but sure it will make me rewrite all my edit actions. >> >> There is "strict dmi" [1] but I doubt that anybody is using it ;-) >> Anyway, doing some improvement in that area is better than removing >> DMI at all ;-) >> Maybe we should switch to strict dmi by default - e.g "execute, input, >> edit, submit, form" are the only allowed methods to be called via DMI. >> And then remove DMI on/off switch at all (DMI will be always enabled). >> >> [1] >> http://struts.apache.org/release/2.3.x/docs/action-configuration.html#ActionConfiguration-DynamicMethodInvocation >> >> >> Regards >> -- >> Łukasz >> + 48 606 323 122 http://www.lenart.org.pl/ >> >> --------------------------------------------------------------------- >> 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
