[
https://issues.apache.org/jira/browse/WW-5688?focusedWorklogId=1037301&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-1037301
]
ASF GitHub Bot logged work on WW-5688:
--------------------------------------
Author: ASF GitHub Bot
Created on: 23/Aug/26 18:48
Start Date: 23/Aug/26 18:48
Worklog Time Spent: 10m
Work Description: lukaszlenart opened a new pull request, #1862:
URL: https://github.com/apache/struts/pull/1862
Fixes [WW-5688](https://issues.apache.org/jira/browse/WW-5688), split out of
the 2008 umbrella [WW-2820](https://issues.apache.org/jira/browse/WW-2820)
(originally reported by Alvin Singh). Of the five claims bundled there, this
was the only one that still reproduced; the other four are dispositioned in a
comment on that ticket, which is now closed.
## The bug
`RestActionMapper` mapped a URI carrying an id into the *default* namespace,
while mapping the same action without an id into `/`. Because
`RuntimeConfiguration.getActionConfig()` only fails over from `/` to `""` and
never the other way round, an action declared in a package with `namespace="/"`
resolved for `index` but 404'd for `show`, `update` and `destroy`:
| Request | namespace from the mapper | resolved before |
|---------|---------------------------|-----------------|
| `GET /dog` | `/` | yes |
| `GET /dog/1` | (empty) | **no - 404** |
## The fix
`DefaultActionMapper` has handled this since **WW-2461** (June 2008) via a
`rootAvailable` check — three months *before* WW-2820 reported the REST
symptom. That fix was never ported to the copy of `parseNameAndNamespace()` the
REST plugin had forked earlier. This PR ports it verbatim, including the
ordering that computes the action name while the namespace is still empty,
since the name is a substring relative to it.
## Blast radius
Deliberately narrow:
- The promotion fires only when a package **explicitly** declares
`namespace="/"` and nothing more specific matched. Convention derives `""` or
`/sub` and never `/`, so it cannot trigger this on its own — the bundled
`rest-showcase` is unaffected.
- Because a `/` lookup already falls back to `""`, the set of resolvable
actions after the change is a strict superset of the previous one. Nothing that
resolved before stops resolving.
- No change to core, and no new configuration surface.
## Tests
- `RestActionMapperRootNamespaceTest` (new) resolves all the way to the
`ActionConfig` rather than stopping at the mapping, because the reported
symptom is a 404. Confirmed RED before the fix: `show`/`update`/`destroy`
failed while `index` and id-extraction passed, so the tests discriminate
exactly this defect.
- `RestActionMapperTest.testParseNameAndNamespaceWithRootPackage` covers the
mapper level, including that a longer declared namespace still outranks the
root. The pre-existing `testParseNameAndNamespace` pins the no-root-package
direction, which is unchanged.
Full rest plugin suite (124 tests) and core's mapper tests (82 tests) pass.
## Not a security fix
Verified before opening: this makes actions *less* reachable rather than
more, and aligning `/dog/1` with what `/dog` already resolves to exposes no
surface the `/dog` path does not already expose.
Backporting to `support/struts-6-x-x` is deliberately left as a separate
decision — it is a behaviour change on a maintenance line.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Issue Time Tracking
-------------------
Worklog Id: (was: 1037301)
Remaining Estimate: 0h
Time Spent: 10m
> RestActionMapper maps URIs with an id into the empty namespace, so actions
> declared at namespace "/" 404
> --------------------------------------------------------------------------------------------------------
>
> Key: WW-5688
> URL: https://issues.apache.org/jira/browse/WW-5688
> Project: Struts 2
> Issue Type: Bug
> Components: Plugin - REST
> Affects Versions: 2.1.2
> Reporter: Lukasz Lenart
> Priority: Major
> Fix For: 7.4.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Split out of [WW-2820|https://issues.apache.org/jira/browse/WW-2820], a 2008
> umbrella of five unrelated REST plugin claims. This is the only one of the
> five that still reproduces on {{main}}. Originally reported by Alvin Singh.
> h3. Symptom
> When a package is declared at namespace {{/}}, REST URIs that carry an id are
> mapped into a _different_ namespace than those that do not. The result is
> that {{index}} works while {{show}} / {{update}} / {{destroy}} return 404 for
> the very same action.
> Given a single package whose namespace attribute is {{/}}, extending
> {{rest-default}}, holding one action named {{dog}}:
> ||Request||namespace from RestActionMapper||action resolves?||
> |{{GET /dog}}|{{/}}|yes|
> |{{GET /dog/1}}|(empty)|_no - 404_|
> The reporter's original phrasing was "if you want a blank namespace, do not
> use / as your namespace ... inconsistent behavior starts to occur", which is
> accurate.
> h3. Root cause
> {{RestActionMapper.parseNameAndNamespace()}} has two disjoint paths:
> * {{lastSlash == 0}} hardcodes {{namespace = "/"}} (the WW-1046 root case).
> * Any deeper URI instead runs the longest-matching-namespace loop. That
> loop's guard, {{prefix.charAt(ns.length()) == '/'}}, can never select {{"/"}}
> - it would require a {{//}} prefix - so it falls through to its default of
> the empty string.
> {{RuntimeConfiguration.getActionConfig()}} then only fails over {{"/"}} to
> the empty namespace, never the empty namespace to {{"/"}} (see
> {{DefaultConfiguration.shouldFallbackToEmptyNamespace}}). So the
> empty-namespace branch is a dead end for an action declared at {{"/"}}.
> Note that the loop computes {{name = uri.substring(namespace.length() + 1)}},
> which assumes a non-root namespace. Simply allowing {{"/"}} to match in the
> loop is therefore not sufficient on its own.
> h3. Reproduction
> Against a configuration holding only the package above:
> {noformat}
> PROBE index -> ns='/' name='dog'
> PROBE show -> ns='' name='dog'
> junit.framework.AssertionFailedError:
> GET /dog/1 must resolve to the action declared in namespace "/"
> {noformat}
> The companion assertion for {{GET /dog}} passes against the same
> configuration, so the failure is specific to the id-bearing URI and not an
> artefact of the fixture.
> h3. Security assessment
> Not a security issue. The defect makes actions _less_ reachable rather than
> more, and aligning {{/dog/1}} with what {{/dog}} already resolves to exposes
> no surface that the {{/dog}} path does not already expose.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
