[
https://issues.apache.org/jira/browse/WW-5535?focusedWorklogId=1006588&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-1006588
]
ASF GitHub Bot logged work on WW-5535:
--------------------------------------
Author: ASF GitHub Bot
Created on: 22/Feb/26 16:00
Start Date: 22/Feb/26 16:00
Worklog Time Spent: 10m
Work Description: lukaszlenart opened a new pull request, #1592:
URL: https://github.com/apache/struts/pull/1592
## Summary
- Fix `DefaultActionProxy.resolveMethod()` to only set
`methodSpecified=false` when defaulting to `"execute"`, not when the method is
resolved from `ActionConfig` (including wildcard substitutions like
`method="{1}"`)
- Update `ActionProxy.isMethodSpecified()` Javadoc to reflect corrected
semantics
- Add unit tests for `isMethodSpecified()` covering explicit,
config-resolved, wildcard, and default cases
Fixes [WW-5535](https://issues.apache.org/jira/browse/WW-5535)
## Problem
For wildcard actions like `<action name="example-*" method="do{1}">`,
`DefaultActionProxy.resolveMethod()` unconditionally set `methodSpecified =
false` when the method wasn't passed explicitly from the URL. This included
methods resolved from `ActionConfig` after wildcard substitution. As a result,
`HttpMethodInterceptor` would skip method-level `@HttpPost`/`@HttpGet`
annotation checks and fall back to class-level annotations — undermining
security validation.
## Fix
Moved `methodSpecified = false` inside the inner `if` block that defaults to
`"execute"`, so it only triggers for the true default case. Methods resolved
from config (including wildcard-substituted values) now correctly report
`isMethodSpecified() == true`.
## Test plan
- [x] `DefaultActionProxyTest` — 4 new tests for `isMethodSpecified()`
semantics (explicit, config, wildcard, default)
- [x] `HttpMethodInterceptorTest` — 3 new tests verifying method-level
annotation checks with wildcard-resolved methods
- [x] All existing tests pass unchanged
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Issue Time Tracking
-------------------
Worklog Id: (was: 1006588)
Remaining Estimate: 0h
Time Spent: 10m
> HttpMethodInterceptor does not work with action names using wildcards
> ---------------------------------------------------------------------
>
> Key: WW-5535
> URL: https://issues.apache.org/jira/browse/WW-5535
> Project: Struts 2
> Issue Type: Bug
> Components: Core Interceptors
> Affects Versions: 6.7.0, 7.0.0
> Reporter: Riccardo Proserpio
> Assignee: Lukasz Lenart
> Priority: Major
> Fix For: 6.9.0, 7.2.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The ActionProxy.isMethodSpecified() method is documented as:
> {noformat}
> Gets status of the method value's initialization.
> Returns: true if the method returned by getMethod() is not a default
> initializer value.
> {noformat}
> However, the implementation in DefaultActionProxy has a different behavior:
>
> {code:java}
> private void resolveMethod() {
> // if the method is set to null, use the one from the configuration
> // if the one from the configuration is also null, use "execute"
> if (StringUtils.isEmpty(this.method)) {
> this.method = config.getMethodName();
> if (StringUtils.isEmpty(this.method)) {
> this.method = ActionConfig.DEFAULT_METHOD;
> }
> methodSpecified = false;
> }
> } {code}
> methodSpecified is set to false not only if the default value is used, but
> also \{*}if methodName is specified via config{*}.
> This method seems to have been introduced long ago as a patch for some DMI
> behavior regression: WW-3628
> The issue happens for example if you specify an action like
> {code:java}
> <action name="example-*" class="aClass" method="aMethod"/>
> {code}
> since the method value is resolved later by wildcard matching.
> The HttpMethodInterceptor uses isSpecifiedMethods to decide when to process
> the invocation:
>
> {code:java}
> if (invocation.getProxy().isMethodSpecified()) {
> Method method =
> action.getClass().getMethod(invocation.getProxy().getMethod());
> // doIntercept...
> }{code}
> thus skipping the validation for actionNames with wildcards.
> I'm not really sure if isMethodSpecified is wrong or has misleading
> documentation. I'm not even sure why the HttpMethodInterceptor should skip
> validation on the default execute methods.
> A fix might be just assessing the existence of
> invocation.getProxy().getMethod() instead on relying on isMethodSpecified,
> but before submitting a pr I'd like the opinion on the maintainers.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
