WW-5535 Fix HttpMethodInterceptor with wildcard action names#1592
Open
lukaszlenart wants to merge 1 commit intomainfrom
Open
WW-5535 Fix HttpMethodInterceptor with wildcard action names#1592lukaszlenart wants to merge 1 commit intomainfrom
lukaszlenart wants to merge 1 commit intomainfrom
Conversation
lukaszlenart
force-pushed
the
fix/WW-5535-http-method-interceptor-wildcard
branch
from
e6ad295 to
803be76
Compare
lukaszlenart
requested review from
aleksandr-m,
cnenning,
jogep,
kusalk,
rgielen,
sdutry and
yasserzamani
DefaultActionProxy.resolveMethod() unconditionally set methodSpecified=false
when the method was not passed explicitly, including when it was resolved from
ActionConfig (e.g., wildcard substitution like method="{1}"). This caused
HttpMethodInterceptor to skip method-level annotation checks for wildcard
actions, falling back to class-level annotations instead.
Move methodSpecified=false inside the inner branch that defaults to "execute",
so config-resolved methods (including wildcard-substituted ones) correctly
report isMethodSpecified()=true. Update Javadoc to reflect the corrected
semantics.
Fixes [WW-5535](https://issues.apache.org/jira/browse/WW-5535)
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
lukaszlenart
force-pushed
the
fix/WW-5535-http-method-interceptor-wildcard
branch
from
803be76 to
fbcb374
Compare
|
4 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
DefaultActionProxy.resolveMethod()to only setmethodSpecified=falsewhen defaulting to"execute", not when the method is resolved fromActionConfig(including wildcard substitutions likemethod="{1}")ActionProxy.isMethodSpecified()Javadoc to reflect corrected semanticsisMethodSpecified()covering explicit, config-resolved, wildcard, and default casesFixes WW-5535
Problem
For wildcard actions like
<action name="example-*" method="do{1}">,DefaultActionProxy.resolveMethod()unconditionally setmethodSpecified = falsewhen the method wasn't passed explicitly from the URL. This included methods resolved fromActionConfigafter wildcard substitution. As a result,HttpMethodInterceptorwould skip method-level@HttpPost/@HttpGetannotation checks and fall back to class-level annotations — undermining security validation.Fix
Moved
methodSpecified = falseinside the innerifblock that defaults to"execute", so it only triggers for the true default case. Methods resolved from config (including wildcard-substituted values) now correctly reportisMethodSpecified() == true.Test plan
DefaultActionProxyTest— 4 new tests forisMethodSpecified()semantics (explicit, config, wildcard, default)HttpMethodInterceptorTest— 3 new tests verifying method-level annotation checks with wildcard-resolved methods🤖 Generated with Claude Code