[
https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14264372#comment-14264372
]
Per Steffensen commented on SOLR-4470:
--------------------------------------
As you noticed. You can configure standard web-container protection in
web.xml/jetty.xml, which makes Jetty require username/password get access. This
means that the requests going in to Solr-nodes (servers) have username/password
added. As long as you send requests from an outside SolrJ client (where you
control the code) you can add the credentials, and you will get access. But
Solr-nodes themselves send requests to other Solr-nodes, and before SOLR-4470
you have no (easy) way to add credentials to those requests - hence they will
not succeed. I guess what happens in you case it that recovery needs to send
inter-solr-node requests that fail due to no-access. To get a nice and easy way
out of this vote for SOLR-4470 (or some other JIRA issue that will make it
possible to add credentials to inter-solr-node requests - e.g. SOLR-6625 will
add a more general feature (callback) that will enable you to get around it).
It might not be entirely impossible for you to get around the problem. Guess
there several more or less hacky options. E.g.
* Some 3rd-party tool that intercepts requests between solr-nodes and add
credentials
* You probably have a well known set of IPs on which the solr-nodes run. You
cannot do it in standard web-container, but Jetty might support configuring a
set of IPs that do not have to authenticate to get access (if that is
acceptable to you). Or maybe you can implement your own bean and plug it into
Jetty.
* Guess you can discard using standard web-container security, and implement it
all yourself. E.g. in a filter that you add in front of SolrDispatchFilter
But I believe it is not easy before SOLR-4470.
Back when I wrote the code for SOLR-4470, I also modified
https://wiki.apache.org/solr/SolrSecurity to show how things will work after
SOLR-4470. Carefully (trying) to note that this depends on SOLR-4470 being
included in the product.
> Support for basic http auth in internal solr requests
> -----------------------------------------------------
>
> Key: SOLR-4470
> URL: https://issues.apache.org/jira/browse/SOLR-4470
> Project: Solr
> Issue Type: New Feature
> Components: clients - java, multicore, replication (java), SolrCloud
> Affects Versions: 4.0
> Reporter: Per Steffensen
> Assignee: Jan Høydahl
> Labels: authentication, https, solrclient, solrcloud, ssl
> Fix For: Trunk
>
> Attachments: SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch,
> SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch,
> SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch,
> SOLR-4470.patch, SOLR-4470_branch_4x_r1452629.patch,
> SOLR-4470_branch_4x_r1452629.patch, SOLR-4470_branch_4x_r1454444.patch,
> SOLR-4470_trunk_r1568857.patch
>
>
> We want to protect any HTTP-resource (url). We want to require credentials no
> matter what kind of HTTP-request you make to a Solr-node.
> It can faily easy be acheived as described on
> http://wiki.apache.org/solr/SolrSecurity. This problem is that Solr-nodes
> also make "internal" request to other Solr-nodes, and for it to work
> credentials need to be provided here also.
> Ideally we would like to "forward" credentials from a particular request to
> all the "internal" sub-requests it triggers. E.g. for search and update
> request.
> But there are also "internal" requests
> * that only indirectly/asynchronously triggered from "outside" requests (e.g.
> shard creation/deletion/etc based on calls to the "Collection API")
> * that do not in any way have relation to an "outside" "super"-request (e.g.
> replica synching stuff)
> We would like to aim at a solution where "original" credentials are
> "forwarded" when a request directly/synchronously trigger a subrequest, and
> fallback to a configured "internal credentials" for the
> asynchronous/non-rooted requests.
> In our solution we would aim at only supporting basic http auth, but we would
> like to make a "framework" around it, so that not to much refactoring is
> needed if you later want to make support for other kinds of auth (e.g. digest)
> We will work at a solution but create this JIRA issue early in order to get
> input/comments from the community as early as possible.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
