[jira] [Work started] (WW-5745) REST plugin authorizes a forward-referenced object-id property at the depth where the reference resolves

["Lukasz Lenart (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/WW-5745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Work on WW-5745 started by Lukasz Lenart.
-----------------------------------------
> REST plugin authorizes a forward-referenced object-id property at the depth where the reference resolves
> --------------------------------------------------------------------------------------------------------
>
>                 Key: WW-5745
>                 URL: https://issues.apache.org/jira/browse/WW-5745
>             Project: Struts 2
>          Issue Type: Bug
>          Components: Plugin - REST
>            Reporter: Lukasz Lenart
>            Assignee: Lukasz Lenart
>            Priority: Minor
>             Fix For: 7.4.0
>
>
> h2. Summary
> When a property refers to an object by {{@JsonIdentityInfo}} id before that object has appeared in the body, Jackson defers the assignment: {{ObjectIdReferenceProperty}} registers a {{PropertyReferring}} and, once the referenced object is deserialized, calls the referring property's {{set()}} from {{handleResolvedForwardReference}}. That call happens wherever the referenced object turns up in the document, which can be at a different nesting depth than the referring property.
> {{AuthorizingSettableBeanProperty.set()}} authorizes with {{ParameterAuthorizationContext.pathFor(memberName)}}, i.e. the member name appended to whatever path prefix is on the stack _at the time of the call_. For a deferred assignment that prefix belongs to the object being deserialized when the reference resolves, not to the bean that owns the referring property, so the path checked is wrong.
> Surfaced by the WW-5727 reviews; pre-existing and independent of that fix.
> h2. Current behaviour
> The mis-computed path can only add a rejection (the wrong prefix is unlikely to be granted), so this fails closed: a correctly annotated forward reference may be dropped with a WARN naming a path the developer never wrote. The first, non-deferred read of the referring property is authorized at the correct path through {{AuthorizingValueDeserializer}}, so no unauthorized value is assigned.
> h2. Proposed change
> Capture the path prefix when the referring property is first read and use it when the deferred {{set()}} runs — e.g. wrap the {{Referring}} Jackson registers, or record the prefix on the wrapper before the reference is deferred. Add a test with two identified objects where the reference appears before its target at a different depth, asserting the referring property binds under its own path when granted and is rejected when not.
> h2. Compatibility notes
> No configuration or API change. Only forward references across nesting depths are affected, and only in the direction of a spurious rejection.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)