[
https://issues.apache.org/jira/browse/SOLR-7274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14490669#comment-14490669
]
Gregory Chanan commented on SOLR-7274:
--------------------------------------
Some initial thoughts...
{code}
--- solr/core/src/java/org/apache/solr/handler/component/HttpShardHandler.java
(revision 1672548)
+++ solr/core/src/java/org/apache/solr/handler/component/HttpShardHandler.java
(working copy)
@@ -215,7 +215,7 @@
if (urls.size() <= 1) {
String url = urls.get(0);
srsp.setShardAddress(url);
- try (SolrClient client = new HttpSolrClient(url, httpClient)) {
+ try (SolrClient client = new HttpSolrClient(url)) {
ssr.nl = client.request(req);
}
} else {
{code}
Why this change?
2. Can we comment on the AuthenticationLayerPlugin? I don't think it's
obvious what needs to be implemented
3. params.put("token.valid", System.getProperty("kerberos.name.rules",
"30"));
This doesn't look correct
4. Using "SolrClient" instead of whatever zookeeper uses (default "Client",
see the code I linked above) for the jaas configuration app name will cause you
to have to deal with two issues. I'm not against doing something different
here, just pointing out that these problems need to be solved before you can
make this change:
A) kerberos tickets need to be refreshed. The zookeeper client automatically
refreshes kerberos tickets, so if you just use the same configuration and app
name, that's handled for you. If you want to use something different, you'll
have to write code to refresh the tickets. This also means you only refresh
the code when using zookeeper (i.e. SolrCloud)...you might want to pull out
support for specifying the plugin via system props (so you know they have to be
using solrcloud in order to read the zk props), or may want to add some error
checking.
B) assuming you want to use the same properties for talking to zookeeper as
talking to other solr servers, you'll have to specify the jaas entry twice
(once for SolrClient, once for Client or whatever zookeeper is using
(ZooKeeperSaslClient.LOGIN_CONTEXT_NAME_KEY). Or you may be able to change how
we handle zookeeper sasl (see SaslACLProvider, I think you'd have to write a
Credentials provider?).
As I said, I'm not against doing this, it just introduces additional issues for
a first version. The code I linked above just uses whatever zookeeper users.
5. In HttpSolrClient.java: "postOrPut.setEntity(new
BufferedHttpEntity(postOrPut.getEntity()));"
Why are we always buffering the http entities? That seems like something that
should be handled by the authentication plugin, i.e. usually we don't buffer.
If we are using kerberos, we set up a client configurer that is smart enough to
handle the http requests for that authentication scheme (here buffering is
probably fine for the initial version, there are some discussions of an
optimization in SOLR-6625). See this comment in SOLR-6625 for some
implementation ideas
https://issues.apache.org/jira/browse/SOLR-6625?focusedCommentId=14238865&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14238865
6. This doesn't seem to handle forwarding requests in the SolrDispatchFilter.
There's more discussion in SOLR-6625, see here:
https://issues.apache.org/jira/browse/SOLR-6625?focusedCommentId=14239957&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14239957
I don't know how to solve that without implementing SOLR-6625, though.
> Pluggable authentication module in Solr
> ---------------------------------------
>
> Key: SOLR-7274
> URL: https://issues.apache.org/jira/browse/SOLR-7274
> Project: Solr
> Issue Type: Sub-task
> Reporter: Anshum Gupta
> Attachments: SOLR-7274.patch
>
>
> It would be good to have Solr support different authentication protocols.
> To begin with, it'd be good to have support for kerberos and basic auth.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
