[
https://issues.apache.org/jira/browse/WW-5759?focusedWorklogId=1045886&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-1045886
]
ASF GitHub Bot logged work on WW-5759:
--------------------------------------
Author: ASF GitHub Bot
Created on: 06/Oct/26 09:50
Start Date: 06/Oct/26 09:50
Worklog Time Spent: 10m
Work Description: lukaszlenart opened a new pull request, #1992:
URL: https://github.com/apache/struts/pull/1992
## Summary
Fixes [WW-5759](https://issues.apache.org/jira/browse/WW-5759)
`StrutsParameterAuthorizer` has to predict which accessor OGNL will use for
a parameter name. It derived that name differently from OGNL in two places,
which this PR aligns:
- **Setters for names like `uRange`.** OGNL 3.4.14 (orphan-oss/ognl#652)
tries the JavaBeans setter `setuRange` before `setURange`. The authorizer only
looked for `setURange`, so `@StrutsParameter` on `setuRange` had no effect. On
a ModelDriven action, an unannotated `setuRange` was also not recognised as the
action's own member.
- **Getters for nested parameters.** The authorizer matched the `java.beans`
property name. `Introspector` names the property of `getURL()` `URL`, while
OGNL reaches `getURL()` for both `uRL.x` and `URL.x`.
### Changes
- `findBindableAccessor` tries `set`, or `is` then `get`, plus each of
OGNL's accessor base names in OGNL's order, and the first name with a match
wins. The existing tie-breaks within one name stay as they were: deepest
declaration first, then an annotated overload.
- The root property is normalised with `Introspector.decapitalize` instead
of lowercasing the first character. That way the candidate list is identical to
the one OGNL builds from the parameter name as written. For example, `URange`
resolves to `setURange` only, exactly as in OGNL.
- OGNL bumped from 3.4.13 to 3.4.14.
## Test plan
- [x] New `ParametersInterceptorTest` cases:
- a JavaBeans-style setter and an uppercase getter on a ModelDriven action
require the annotation
- the annotation counts only on the setter OGNL invokes
- case variants of an accessor name bind nothing
- [x] Core 3405 tests, plus the JSON, REST, Tiles, Spring, CDI and
Convention plugins: 0 failures
- [ ] CI
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Issue Time Tracking
-------------------
Worklog Id: (was: 1045886)
Remaining Estimate: 0h
Time Spent: 10m
> @StrutsParameter enforcement resolves accessor names differently from OGNL
> --------------------------------------------------------------------------
>
> Key: WW-5759
> URL: https://issues.apache.org/jira/browse/WW-5759
> Project: Struts 2
> Issue Type: Task
> Components: Core
> Reporter: Lukasz Lenart
> Assignee: Lukasz Lenart
> Priority: Major
> Fix For: 7.5.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{StrutsParameterAuthorizer}} has to decide which accessor OGNL will go
> through for a parameter name, and it derives that name differently from OGNL
> in two places.
> h3. 1. Setters for names like {{uRange}} (OGNL 3.4.14 and later)
> OGNL 3.4.14 (orphan-oss/ognl#652, backport of #644) resolves
> JavaBeans-compliant accessors: for a property {{uRange}} it tries
> {{setuRange}} first and {{setURange}} second. {{findBindableAccessor}} only
> looks for {{set}} plus the capitalised name, i.e. {{setURange}}.
> Two symptoms follow:
> * {{@StrutsParameter}} on {{setuRange}} has no effect: the parameter is
> rejected (fails closed).
> * On a ModelDriven action, an unannotated {{setuRange}} on the action is not
> seen as the action's own member, so the parameter takes the "declared on
> neither the model nor the action" fallback and OGNL binds it through that
> setter. The same family as WW-5709 (fluent setters).
> With OGNL 3.4.13, which Struts currently ships, OGNL never reaches
> {{setuRange}}, so this only appears once OGNL is upgraded - by Struts or by
> an application that overrides the OGNL version.
> h3. 2. Getters for nested parameters
> For a nested parameter the authorizer matches the {{java.beans}} property
> name. {{Introspector}} names the property of {{getURL()}} {{URL}}, while OGNL
> reaches {{getURL()}} for both {{uRL.host}} and {{URL.host}}. On a ModelDriven
> action an unannotated {{getURL()}} on the action therefore also takes the
> "declared on neither" fallback. This one is independent of the OGNL version.
> h3. Suggested fix
> Resolve accessors exactly the way OGNL does: try {{set}} (or {{is}} then
> {{get}}) plus each accessor base name in OGNL's order, first match wins, and
> normalise the root property with {{Introspector.decapitalize}} so the
> candidate list matches OGNL's for the parameter name as written. Bump OGNL to
> 3.4.14 in the same change.
> Found while upgrading to OGNL 3.5 (WW-5326).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)