Am 08.11.2014 um 17:49 schrieb Lukasz Lenart:
2014-11-07 16:44 GMT+01:00 Volker Krebs <volker.kr...@abas.de>:
Yes my workaround was to directly exclude orderinfo param.
I don't know if it is broken. But when the behavior of
<param name="acceptParamNames">param1</param>
should be to ignore every parameter but param1, then it's not working as
expected.
I found where the problem is. Right now "acceptParamNames" are added
to existing ACCEPTED_PATTERNS defined in
DefaultAcceptedPatternsChecker - previously "acceptParamNames" were
overriding default patterns from ACCEPTED_PATTERNS.
You can still override the default patterns with
"struts.override.excludedPatterns" and then use "acceptParamNames" to
relax the those global patterns. Or you can implement your own version
of AcceptedPatternsChecker.
Basically I have to update docs about that. It was introduced by that
PR -> https://github.com/apache/struts/pull/11
The question is if this is a better solution? You have a lot of
options to check accepted params but maybe it's too complicated? Let
me know what you think.
My application was relying that certain parameters were blocked.
So adding global accept pattern could break backwards compatibility.
I think when defining acceptParamNames only those should be passed
to the action. Everything else should be blocked. (white list approach)
When not defining any acceptParamNames all parameters should be passed
except the ones in the excludedPatterns. (black list approach)
The black list approach is difficult, because you
will definitely forget some patterns. But a pure white list approach
would break a lot of applications. Because everybody must define the
parameters he needs.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
