[
https://issues.apache.org/jira/browse/ZOOKEEPER-2346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15702817#comment-15702817
]
Meyer Kizner commented on ZOOKEEPER-2346:
-----------------------------------------
It's a little difficult to write a regression test for this issue specifically,
because the bug is a race condition, so two different behaviors can be
observed. I believe the Java client already has tests for SASL authentication
failure, which leads me to believe that the race will be hard to reproduce in
the test--I haven't put much thought into it, though. (The C client doesn't
have SASL support.)
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
wasn't sure of the implications of this for compatibility, though, so I left it
as is. Do you have any thoughts on that?
If the patch you're working on is a superset of this change, I'd be happy to
wait and review it. It would be nice to get this change in 3.4.x though.
> 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)
