Mailing-List: contact jira-help@kafka.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jira@kafka.apache.org
Date: Fri, 30 Jun 2017 18:04:00 +0000 (UTC)
From: "Jason Gustafson (JIRA)" <jira@apache.org>
To: jira@kafka.apache.org
Message-ID: <JIRA.13083878.1498845790000.148110.1498845840336@Atlassian.JIRA>
In-Reply-To: <JIRA.13083878.1498845790000@Atlassian.JIRA>
References: <JIRA.13083878.1498845790000@Atlassian.JIRA> <JIRA.13083878.1498845790258@jira-lw-us.apache.org>
Subject: [jira] [Created] (KAFKA-5547) Return topic authorization failed if
 no topic describe access
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Fri, 30 Jun 2017 18:04:04 -0000

Jason Gustafson created KAFKA-5547:
--------------------------------------

             Summary: Return topic authorization failed if no topic describe access
                 Key: KAFKA-5547
                 URL: https://issues.apache.org/jira/browse/KAFKA-5547
             Project: Kafka
          Issue Type: Improvement
            Reporter: Jason Gustafson


We previously made a change to several of the request APIs to return UNKNOWN_TOPIC_OR_PARTITION if the principal does not have Describe access to the topic. The thought was to avoid leaking information about which topics exist. The problem with this is that a client which sees this error will just keep retrying because it is usually treated as retriable. It seems, however, that we could return TOPIC_AUTHORIZATION_FAILED instead and still avoid leaking information as long as we ensure that the Describe authorization check comes before the topic existence check. This would avoid the ambiguity on the client.


--
This message was sent by Atlassian JIRA
(v6.4.14#64029)