[
https://issues.apache.org/jira/browse/WW-4323?focusedWorklogId=1049254&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-1049254
]
ASF GitHub Bot logged work on WW-4323:
--------------------------------------
Author: ASF GitHub Bot
Created on: 22/Oct/26 10:08
Start Date: 22/Oct/26 10:08
Worklog Time Spent: 10m
Work Description: lukaszlenart opened a new pull request, #2049:
URL: https://github.com/apache/struts/pull/2049
Relates to [WW-4323](https://issues.apache.org/jira/browse/WW-4323) (closed
as Won't Fix)
## Summary
`ParametersInterceptor#isAcceptableParameter` sets a parameter only when
**both** the global name checks and
`ParameterNameAware#acceptableParameterName` accept it. This has been the rule
since 2.3.16.1 (`4e98aaaa1`, WW-4109 / WW-4154). WW-4323 asked to go back to
the old "either check" behaviour, and that request was declined.
The existing `testParameterNameAware` doesn't distinguish the two
behaviours, because its action already rejects every extra key itself. The new
test uses an action that accepts every name plus an excluded `blockedKey`, and
asserts that only `allowedKey` gets bound.
## Test plan
- [x] `mvn test -DskipAssembly -pl core
-Dtest='ParametersInterceptorTest#testParameterNameAware*'` runs 2 tests, both
pass
- [x] Checked that the test catches a regression: an interceptor subclass
that restores the old "either check" logic fails with
`expected:<{allowedKey=allowedValue}> but was:<{allowedKey=allowedValue,
blockedKey=blockedValue}>`
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Issue Time Tracking
-------------------
Worklog Id: (was: 1049254)
Remaining Estimate: 0h
Time Spent: 10m
> 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
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> 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)
