[
https://issues.apache.org/jira/browse/WW-5727?focusedWorklogId=1041558&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-1041558
]
ASF GitHub Bot logged work on WW-5727:
--------------------------------------
Author: ASF GitHub Bot
Created on: 15/Sep/26 05:54
Start Date: 15/Sep/26 05:54
Worklog Time Spent: 10m
Work Description: lukaszlenart opened a new pull request, #1943:
URL: https://github.com/apache/struts/pull/1943
Fixes [WW-5727](https://issues.apache.org/jira/browse/WW-5727)
## Problem
On a type whose `@JsonIdentityInfo` uses a property-based generator,
`BeanDeserializerFactory.addObjectIdReader` runs before the deserializer
modifiers and captures the id `SettableBeanProperty` into the `ObjectIdReader`.
`ParameterAuthorizingModule.updateBuilder` then wraps every property in the
builder, but the `ObjectIdValueProperty` Jackson adds at build time assigns the
id through the reader's captured property — the unwrapped one — so the id binds
without a `@StrutsParameter` check. With `id` rejected,
`{"id":7,"name":"alice"}` still set `id` to 7.
Sibling of WW-5725 and WW-5726: a Jackson path that takes hold of the
property before the modifier can wrap it.
## Change
- After wrapping, the module rebuilds the reader with
`ObjectIdReader.construct(...)` around a wrapper of `reader.idProperty`,
keeping the id type, property name, generator, deserializer and resolver. The
id is then assigned through the wrapper's `setAndReturn` and authorized like
any other property. Sequence-style generators carry no id property and are left
alone.
- `AuthorizingSettableBeanProperty.set`/`setAndReturn` are no-ops over a
`CreatorProperty`. Jackson skips the post-construction write of a creator-bound
id itself by an `instanceof CreatorProperty` check the wrapper hides
(databind#5328), and a record has no setter to write through — wrapping the id
plainly broke every record with a property-based id, both through the builder's
reader and through the one `createContextual` builds for a `@JsonIdentityInfo`
placed on the *referencing* property. Leaving the reader alone for creator ids
was not an option: a repeated id key after construction wrote the creator
property's fallback field unchecked.
## Behaviour note
A key for a creator-bound property repeated after construction is now
dropped, where stock Jackson pushes it through the creator property's fallback
field (or throws for a record). The wrapper cannot tell that write from the one
Jackson skips itself, so the creator's value stands. This applies whether or
not authorization is active; it only affects bodies that repeat the key.
## Tests
`ParameterAuthorizingModuleTest`: id rejected / granted on a plain bean;
record with a property-based id — no context, authorized, rejected;
per-property `@JsonIdentityInfo` on a record-typed member — no context and
rejected; repeated id key after construction keeps the creator's value.
`mvn test -DskipAssembly -pl plugins/rest`: 192 tests, 0 failures.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Issue Time Tracking
-------------------
Worklog Id: (was: 1041558)
Remaining Estimate: 0h
Time Spent: 10m
> The @JsonIdentityInfo id property is not authorized in the REST plugin
> ----------------------------------------------------------------------
>
> Key: WW-5727
> URL: https://issues.apache.org/jira/browse/WW-5727
> Project: Struts 2
> Issue Type: Bug
> Components: Plugin - REST
> Reporter: Lukasz Lenart
> Assignee: Lukasz Lenart
> Priority: Major
> Fix For: 7.4.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> h2. Summary
> On a type annotated with {{@JsonIdentityInfo}} using a property-based
> generator, the id property is assigned through Jackson's {{ObjectIdReader}},
> which holds a reference to the property captured before
> {{ParameterAuthorizingModule}} runs. The reader writes through that original
> property, so the authorization wrapper installed by the module is never
> consulted and the id is assigned without a check.
> Sibling of WW-5725 and WW-5726: a Jackson path that takes hold of the
> property before the deserializer modifier can wrap it.
> h2. Current behaviour
> {{BeanDeserializerFactory.buildBeanDeserializer}} calls {{addObjectIdReader}}
> before applying the deserializer modifiers. {{addObjectIdReader}} looks the
> id property up in the builder and stores it in the {{ObjectIdReader}} it
> constructs. {{ParameterAuthorizingModule.updateBuilder}} then replaces every
> property in the builder with {{AuthorizingSettableBeanProperty}}, but the
> {{ObjectIdReader}} still refers to the property it captured.
> At deserialization time the {{ObjectIdValueProperty}} that Jackson adds for
> the id delegates to {{ObjectIdReader.idProperty.setAndReturn(...)}}, i.e. to
> the unwrapped property. With an authorizer that rejects {{id}}, a body of
> {{{"id": 7, "name": "alice"}}} still sets {{id}} to 7 while {{name}} is
> handled normally.
> Members of such a type other than the id are unaffected. 6.x is unaffected:
> the REST plugin there has no Jackson authorization module.
> h2. Proposed change
> In {{ParameterAuthorizingModule.updateBuilder}}, after the properties have
> been wrapped, check {{builder.getObjectIdReader()}}. If one is present,
> construct a replacement with {{ObjectIdReader.construct(...)}} carrying the
> same id type, property name, generator, resolver and deserializer, but with
> the wrapped id property, and set it back on the builder. The reader's fields
> are all available for that.
> Add a test with a {{@JsonIdentityInfo(generator =
> ObjectIdGenerators.PropertyGenerator.class, property = "id")}} type: with
> {{id}} rejected the field must keep its default, with {{id}} granted it must
> be assigned.
> h2. Compatibility notes
> No configuration or API change. An id property on such a type is now subject
> to the same {{@StrutsParameter}} authorization as any other property; an
> application relying on it being bound without a grant needs to annotate it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
