[
https://issues.apache.org/jira/browse/WW-5720?focusedWorklogId=1041759&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-1041759
]
ASF GitHub Bot logged work on WW-5720:
--------------------------------------
Author: ASF GitHub Bot
Created on: 15/Sep/26 17:48
Start Date: 15/Sep/26 17:48
Worklog Time Spent: 10m
Work Description: lukaszlenart merged PR #1948:
URL: https://github.com/apache/struts/pull/1948
Issue Time Tracking
-------------------
Worklog Id: (was: 1041759)
Time Spent: 40m (was: 0.5h)
> 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
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> 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)
