zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Han (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ZOOKEEPER-2346) SASL Auth failure manifested to client as connection refusal
Date Mon, 28 Nov 2016 19:44:58 GMT

    [ https://issues.apache.org/jira/browse/ZOOKEEPER-2346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15702915#comment-15702915

Michael Han commented on ZOOKEEPER-2346:

bq. One way to make this testable would be to have the server return the auth failed error
code in the reply header, instead of just sending a null token. 

I think this is what I am actually doing in ZOOKEEPER-1634 - client would now get typed keeper
exception such as AuthFailed rather than getting a ConnectionLoss exception which is too generic
for client such as Curator to handle as ConnectionLoss could be caused by many things. I added
tests / updated existing ones so the tests verify that an expected type of KeeperException
will be observed on client side, instead of the generic ConnectionLoss exception, which is
the key benefit of the change proposed here (to have server gracefully ask client to close
cnx instead of having server itself do it.).

bq. The C client doesn't have SASL support.
Good point - I forgot the context here is this JIRA instead of ZOOKEEPER-1634 where i do need
C tests for regression :)

> SASL Auth failure manifested to client as connection refusal
> ------------------------------------------------------------
>                 Key: ZOOKEEPER-2346
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2346
>             Project: ZooKeeper
>          Issue Type: Bug
>          Components: server
>    Affects Versions: 3.4.6
>            Reporter: Steve Loughran
>            Assignee: Meyer Kizner
>         Attachments: ZOOKEEPER-2346.patch, ZOOKEEPER-2346.patch
> If a client can't authenticate via sasl then (a) the stack trace is lost on the server
logs, and (b) it is exposed to the client as a connection refusal. This results in curator
retrying many times before giving up —and with the cause being misinterpreted as a server-down
problem, rather than a client-not-trusted problem

This message was sent by Atlassian JIRA

View raw message