[jira] [Assigned] (WW-5720) AuthorizingSettableAnyProperty logs one WARN per rejected dynamic key

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

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

Lukasz Lenart reassigned WW-5720:
---------------------------------

    Assignee: Lukasz Lenart

> AuthorizingSettableAnyProperty logs one WARN per rejected dynamic key
> ---------------------------------------------------------------------
>
>                 Key: WW-5720
>                 URL: https://issues.apache.org/jira/browse/WW-5720
>             Project: Struts 2
>          Issue Type: Improvement
>          Components: Plugin - REST
>            Reporter: Lukasz Lenart
>            Assignee: Lukasz Lenart
>            Priority: Minor
>             Fix For: 7.4.0
>
>
> Follow-up to WW-5712.
> When {{struts.rest.anySetter.requireAnnotations}} is enabled, {{AuthorizingSettableAnyProperty.rejectPermission}} and {{rejectDepth}} emit a WARN for every rejected dynamic key. For the existing {{AuthorizingSettableBeanProperty}} a per-property WARN is fine, because the set of property names is bounded by the target class's declared members. For an any-setter the key space is whatever the request body contains, so the number of WARN lines written per request is bounded only by the body itself: a body with ten thousand unknown keys against an unannotated sink produces ten thousand WARN lines.
> Log once per body instead. Suggested shape:
> * keep the per-key detail at DEBUG;
> * count rejections per request in the same request-scoped state that {{DynamicKeyAuthorizationContext}} already holds, and emit a single WARN with the count and the sink (target class plus member) when the scope is cleared at the end of the mapper read, which both Jackson handlers already do in a {{finally}};
> * keep the distinct messages for the three rejection reasons (missing consent, depth exceeded, creator-parameter form), since they point at different fixes on the application side.
> The rejection behaviour itself does not change; only the log volume does.



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