[jira] [Commented] (KAFKA-9510) Quotas may resolve to incorrect value if user is empty

["Brian Byrne (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/KAFKA-9510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17031080#comment-17031080 ] 

Brian Byrne commented on KAFKA-9510:
------------------------------------

Here's another one that may be more common.

/config/clients/<default>, producer_byte_rate=1000
request: (user="test", client-id="")

Resolves to Long.MaxValue since quotaMetricsTags resolves to ("", clientId) -> ("", "").


> Quotas may resolve to incorrect value if user is empty
> ------------------------------------------------------
>
>                 Key: KAFKA-9510
>                 URL: https://issues.apache.org/jira/browse/KAFKA-9510
>             Project: Kafka
>          Issue Type: Bug
>            Reporter: Brian Byrne
>            Assignee: Rajini Sivaram
>            Priority: Major
>             Fix For: 2.6.0
>
>
> This may be a pretty rare/uncommon case that I encountered during testing regarding an empty user. [~rsivaram] please let me know if this is a valid bug and whether it's something that's needs further examination.
> Let's say two quota configurations are populated:
> /config/users/<default> {producer_byte_rate=500}
> /config/clients/<default> {producer_byte_rate=1000}
> And let's say a produce request with {user="", client-id="test"} enters the system. When calling ClientQuotaManager::quota(), the metrics tags that are fetched via ClientQuotaCallback::quotaMetricTags() will map to the config entry for /config/users/<default>, which is (sanitizedUser, ""), where substituting gets ("", "").
> Then, when looking up the quota in ClientQuotaCallback::quotaLimit(), both tags are the empty string, which resolves to null, which turns into Long.MaxValue for the result. So where the client may have expected 500 (or 1000?), it's instead unbounded.
> Is it valid for a request to ever contain an empty string for the user? If so, then a fix will be needed, otherwise if not, we should safeguard against this from happening.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)