[
https://issues.apache.org/jira/browse/SOLR-14070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17017006#comment-17017006
]
Jan Høydahl commented on SOLR-14070:
------------------------------------
bq. ZK could have been firewalled if the clients wouldn't talk to them directly.
CloudSolrClient already supports bootsrapping from Solr URLs, which would be
the recommended way. It is also easier to implement in Solr clients for other
languages such as PHP, C# etc without worrying about ZK. So. you are free to
firewall your ZK today if you wish :)
I'm +0 on the idea. We could deprecate and then not remove it until v10.0, just
to force users into reconsidering their choice. We could also add more JavaDocs
to the deprecated constructor, reminding people to limit access to their ZK as
much as possible.
> Deprecate CloudSolrClient's ZKHost constructor
> ----------------------------------------------
>
> Key: SOLR-14070
> URL: https://issues.apache.org/jira/browse/SOLR-14070
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Ishan Chattopadhyaya
> Priority: Major
>
> CloudSolrClient can be used by pointing it to a ZK cluster. This is
> inherently insecure.
> CSC can already be used in all the same ways by pointing it to a Solr cluster.
> Proposing to add a deprecation notice to the following constructor to the
> CloudSolrClient#Builder:
> {code}
> public Builder(List<String> zkHosts, Optional<String> zkChroot)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
