[
https://issues.apache.org/jira/browse/WW-5746?focusedWorklogId=1041603&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-1041603
]
ASF GitHub Bot logged work on WW-5746:
--------------------------------------
Author: ASF GitHub Bot
Created on: 15/Sep/26 09:54
Start Date: 15/Sep/26 09:54
Worklog Time Spent: 10m
Work Description: lukaszlenart opened a new pull request, #1945:
URL: https://github.com/apache/struts/pull/1945
Fixes [WW-5746](https://issues.apache.org/jira/browse/WW-5746)
## Problem
The `ObjectIdReader` reads a property-based `@JsonIdentityInfo` id through
its own deserializer (resolved by `BeanDeserializerFactory` for the id type),
not through the id property's value deserializer, so nothing pushed a path
prefix for it. When the id type is a bean, its members were authorized at the
enclosing bean's level — `k` instead of `id.k` — and a grant on a same-named
member of the enclosing bean authorized the write into the id. The `id`
property itself has been gated since WW-5727; this is the path its members are
checked under.
## Change
- New `ObjectIdPathDeserializer`: pushes the id property's path around the
reader's deserializer. It authorizes and redacts nothing — the `id` property is
checked when it is assigned, and Jackson cannot bind or resolve a `null` id. A
scalar id sees no difference.
- `ParameterAuthorizingModule.authorizedObjectIdReader` now rebuilds the
reader around both the wrapped id property (WW-5727) and this deserializer, and
the rebuild is shared with a new `RedactionAwareDeserializer.createContextual`
override: a `@JsonIdentityInfo` placed on the *referring property* makes
Jackson build a fresh reader there, after the modifier ran, so the class-level
rebuild alone left that path open (review-found, probe-verified, now tested).
Not covered, documented in Javadoc: a `@JsonFormat(shape = ARRAY)` bean with
a property-level identity keeps its ordered-property array across
`withObjectIdReader`, which this wrapper cannot reach — identical to `main`.
Not testable: a creator-bound bean with a bean-typed id — Jackson reads such an
id twice and the creator parameter ends up empty regardless of authorization.
Jackson's property-based generator never parses an object token as a
reference, so a reference by id structure is not a reachable shape; a custom
generator that allowed it would see the reference under the referring
property's `id`, where it sits in the body.
## Related
The reviews surfaced a pre-existing defect in `RedactionAwareDeserializer` —
it does not resync the parser after dropping an object mid-read, so a dropped
object's remaining fields are consumed by the parent — filed as
[WW-5747](https://issues.apache.org/jira/browse/WW-5747).
## Tests
`ParameterAuthorizingModuleTest`: bean-typed id members rejected under
`id.k` despite a top-level `k` grant, bound when `id.k` is granted, and the
same for a `@JsonIdentityInfo` declared on the referring property.
`mvn test -DskipAssembly -pl plugins/rest`: 202 tests, 0 failures. Two
code-review and two security-review passes; nothing newly introduced.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Issue Time Tracking
-------------------
Worklog Id: (was: 1041603)
Remaining Estimate: 0h
Time Spent: 10m
> Members of a bean-typed @JsonIdentityInfo id are authorized at the enclosing
> path in the REST plugin
> ----------------------------------------------------------------------------------------------------
>
> Key: WW-5746
> URL: https://issues.apache.org/jira/browse/WW-5746
> Project: Struts 2
> Issue Type: Bug
> Components: Plugin - REST
> Reporter: Lukasz Lenart
> Assignee: Lukasz Lenart
> Priority: Minor
> Fix For: 7.4.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> h2. Summary
> For a type using a property-based {{@JsonIdentityInfo}}, the id value is read
> by {{ObjectIdValueProperty}} through the {{ObjectIdReader}}'s own
> deserializer, which {{BeanDeserializerFactory.addObjectIdReader}} resolves
> with {{findRootValueDeserializer(idType)}}. That deserializer is not the
> property's value deserializer, so it is not wrapped by
> {{AuthorizingValueDeserializer}} and pushes no path prefix. When the id type
> is a bean rather than a scalar, its members are therefore authorized at the
> enclosing bean's level — {{k}} instead of {{id.k}} — and a grant on a
> same-named property of the enclosing bean authorizes the nested write.
> The id property itself is gated at {{id}} since WW-5727 (assignment goes
> through the wrapped property's {{setAndReturn}}), so an id value is never
> assigned without a grant on {{id}}; the gap is the path its members are
> checked under. Surfaced by the WW-5727 reviews; pre-existing and independent
> of that fix.
> h2. Current behaviour
> With an authorizer granting {{id}} and {{k}} on the enclosing bean, a body
> {{{"id": {"k": "x"}}}} on a type whose id is a bean with member {{k}} binds
> {{id.k}} on the strength of the grant for the top-level {{k}}. A scalar id is
> unaffected.
> h2. Proposed change
> Wrapping the reader's deserializer is not a drop-in fix: the same
> deserializer is used by {{ObjectIdReader.readObjectReference}} to read
> _references_ to already-seen objects, where no property is being assigned and
> no prefix applies. The push has to happen only on the
> {{ObjectIdValueProperty}} value path — e.g. rebuild the reader in
> {{ParameterAuthorizingModule.authorizeObjectIdProperty}} with a deserializer
> that pushes {{pathFor(memberName)}} around the delegate for the value read,
> while references keep the bare one; or wrap the {{ObjectIdValueProperty}}
> after build. Add a test with a bean-typed id where the enclosing bean has a
> same-named member, asserting the nested member is rejected under {{id.k}} and
> bound when {{id.k}} is granted.
> h2. Compatibility notes
> No configuration or API change. Only bean-typed ids under a property-based
> generator are affected, an unusual shape; an application relying on the
> enclosing grant for the id's members needs a grant at the nested path instead.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
