[
https://issues.apache.org/jira/browse/WW-4323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18130224#comment-18130224
]
Lukasz Lenart commented on WW-4323:
-----------------------------------
Closing as Won't Fix — the current behaviour is intentional.
Since 2.3.16.1 (commit {{4e98aaaa1}}, WW-4109 / WW-4154) a parameter is set
only when *both* the interceptor's global name checks (length limit, accepted
patterns, excluded patterns) *and*
{{ParameterNameAware#acceptableParameterName}} accept it. Struts 7.x keeps
exactly that rule in {{ParametersInterceptor#isAcceptableParameter}}, together
with the {{@StrutsParameter}} allowlist. The global checks are the framework's
baseline validation for parameter names, so they should not be overridable from
action code. {{ParameterNameAware}} can narrow what an action accepts but
cannot widen it.
We also looked at adding a per-action switch to choose between the two
behaviours, and decided against it. It would let one method in action code turn
off the baseline checks for every parameter that action receives.
If an action needs parameter names that the defaults reject, relax the rules
for that action through the interceptor parameters in its configuration, for
example:
{code:xml}<interceptor-ref name="defaultStack">
<param name="params.acceptParamNames">...</param>
</interceptor-ref>
{code}
This keeps the relaxation visible in configuration as a regex that can be
reviewed. In 7.x, {{@StrutsParameter}} is the preferred way to declare which
parameters an action accepts.
The struts-site page for the Parameters Interceptor still says that
{{ParameterNameAware}} "takes precedence" over the interceptor. That has not
been true since 2.3.16.1, and the page will be corrected.
> Ability to accept params purely by implementing ParamNameAware is broken
> ------------------------------------------------------------------------
>
> Key: WW-4323
> URL: https://issues.apache.org/jira/browse/WW-4323
> Project: Struts 2
> Issue Type: Bug
> Affects Versions: 2.3.16.1
> Environment: struts2 version 2.3.16.1
> Reporter: Kyle Braak
> Priority: Major
> Fix For: 7.5.0
>
>
> The ability to accept params purely by implementing ParamNameAware is broken.
> Relates to WW-3866 which is when this feature was added for version 2.3.5
> The commit that breaks this feature is:
> https://github.com/apache/struts/commit/4e98aaaa1b08cc37374d06e77cf78000d98c5ff0
> Description:
> Prior to this change/2.3.16.1 it was quite convenient to define what
> parameters my action should accept, by implementing
> ParameterNameAware#acceptableParameterName. With this change, there is the
> additional requirement that the parameter names must also satisfy
> acceptableName(name).
> In the ParametersInterceptor javadoc, it says: "if you wish to apply a global
> rule that isn't implemented in your action, then you could extend this
> interceptor and override the {@link #acceptableName(String)} method." So this
> isn't suitable for customizing a single action.
> Looking more carefully at the code, another alternative to defining what
> parameters my action can accept, looks to be via populating the
> ParametersInterceptor's field acceptParams. Apparently this could be done in
> the interceptor stack from what I have read here:
> http://struts.apache.org/release/2.3.x/docs/parameters-interceptor.html
> By forcing one to populate acceptParams, and also implement
> ParameterNameAware#acceptableParameterName it becomes quite difficult to add
> custom behavior. I understand people should fully understand what they are
> doing due to the security risks involved, but it is probably safer to define
> the behavior in a single place.
> I'd greatly appreciate your help understanding how to adapt to this change.
> In the meantime, I'll have to continue using 2.3.15.3
> Thanks
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
