You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@kafka.apache.org by "Brian Byrne (Jira)" <ji...@apache.org> on 2020/02/05 21:58:00 UTC

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

Brian Byrne created KAFKA-9510:
----------------------------------

             Summary: 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
             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)