[
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
(v6.3.4#6332)
