WW-5642 fix(rest): authorize @StrutsParameter on record/creator-bound REST body properties

[g0w6y]

Fixes WW-5642

Summary

ParameterAuthorizingModule enforces @StrutsParameter on REST/JSON body deserialization by wrapping each Jackson property's deserializeAndSet / deserializeSetAndReturn (AuthorizingSettableBeanProperty). Jackson never calls either method for creator-bound properties — Java records, @JsonCreator constructors, @ConstructorProperties — it instead calls SettableBeanProperty#deserialize directly, which Jackson declares final, so the existing wrapper cannot intercept it.

Practical effect: with struts.parameters.requireAnnotations enabled, any record-typed field anywhere in a REST action's request body (top-level or nested) is populated with no @StrutsParameter check at all, silently defeating the protection for that entire subtree. This is easy to hit unintentionally — record is the idiomatic way to model immutable REST DTOs on the Java versions Struts now targets.

Verified with a live reproduction before writing the fix: a record field with an unauthorized component was populated anyway; after the fix, the same component is correctly rejected while an authorized sibling component still passes through.

Fix

Add AuthorizingValueDeserializer, which wraps the property's value deserializer rather than the SettableBeanProperty — the value deserializer is what the final deserialize() method delegates to, so wrapping it is the only available interception point for the creator-bound path. It is installed from AuthorizingSettableBeanProperty#withValueDeserializer, scoped to CreatorProperty specifically, so ordinary setter/field/builder-pattern properties — already correctly authorized via the existing deserializeAndSet/deserializeSetAndReturn overrides — are not checked a second time (which would also double-push the path-authorization stack and produce incorrect nested paths).

Test plan

• New regression test testRecordComponentAuthorizedByPath in ParameterAuthorizingModuleTest: a record-typed nested property with one authorized and one unauthorized component — confirms the unauthorized component is rejected and the authorized one still deserializes.
• Full existing ParameterAuthorizingModuleTest suite (setter, builder, nested, collection, map, array authorization paths) passes unchanged — confirms no regression from scoping the new check to creator-bound properties only.
• Full struts2-rest-plugin module test suite passes (106/106).

[lukaszlenart]

Thanks for the PR but please create a JIRA ticket to cover this work 🙏

[g0w6y]

Created WW-5642 to track this: https://issues.apache.org/jira/browse/WW-5642. Ready for review/merge whenever you get a chance — thanks!

[g0w6y]

Given this fixes an authorization bypass where unauthorized REST body fields could be set, should we handle this as a security advisory instead of a normal fix? Happy to follow whichever process you prefer, just let me know.