[
https://issues.apache.org/jira/browse/ZOOKEEPER-1764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13777752#comment-13777752
]
Kuba Skopal commented on ZOOKEEPER-1764:
----------------------------------------
That satisfies my case perfectly, thanks!
Long term I'd say having a property on zoo object would be better though as
that would make it easily configurable from Spring, etc...
> ZooKeeper attempts at SASL eventhough it shouldn't
> --------------------------------------------------
>
> Key: ZOOKEEPER-1764
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1764
> Project: ZooKeeper
> Issue Type: Bug
> Components: java client
> Affects Versions: 3.4.4
> Reporter: Kuba Skopal
>
> We are using a proprietary SASL solution, but we don't want to use it with
> ZooKeeper. Unfortunately it seems, that there is no way to disable SASL for
> ZooKeeper as the code only checks for presence of
> "java.security.auth.login.config" system property to determine whether SASL
> should be used or not.
> For us it means, that ZooKeeper client just shuts down after SASL is
> initialized. What happens:
> 1) System.getProperty("java.security.auth.login.config") is initially null
> 2) ZooKeeper is initialized and used
> 3) Our JAAS/SASL component is initialized
> 4) System.getProperty("java.security.auth.login.config") is not null anymore
> 5) ZooKeeperSaslClient.clientTunneledAuthenticationInProgress() suddenly
> picks up the new property and starts returning true
> 6) ClientCnxnSocketNIO.findSendablePacket() suddenly stops returning any
> packets since clientTunneledAuthenticationInProgress is always true
> The communication is halted and eventually times out.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
