[
https://issues.apache.org/jira/browse/WW-5746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukasz Lenart resolved WW-5746.
-------------------------------
Resolution: Fixed
> 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: 40m
> 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)
