[
https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13955084#comment-13955084
]
Per Steffensen commented on SOLR-4470:
--------------------------------------
Regarding the following FIXME in SolrCmdDistributor
{quote}
// FIXME Here it is a problem using StreamingSolrServers which uses
ConcurrentUpdateSolrServer for its requests. They (currently)
// do not respond errors back, and users of SolrCmdDistributor actually ought
to get errors back, so that they can eventually
// be reported back to the issuer of the outer request that triggers the
SolrCmdDistributor requests.
// E.g. if you issue a deleteByQuery() from a client you will not get any
information back about whether or not it was actually
// carried out successfully throughout the complete Solr cluster. See
workaround in SecurityDistributed.doAndAssertSolrExeptionFromStreamingSolrServer
{quote}
The text is a little misleading. Actually SolrCmdDistributor,
StreamingSolrServers and ConcurrentUpdateSolrServers do collect errors and make
them available for the components using them. Problem is that
DistributedUpdateProcessor.doFinish does not report the errors back to the
outside client in case there are more than one error (see comment "// TODO - we
may need to tell about more than one error..." in
DistributedUpdateProcessor.doFinish. The two places in SecurityDistributedTest
that uses doAndAssertSolrExeptionFromStreamingSolrServer expect to get an
exception back, but does not because both subrequests made internally by
SolrCmdDistributor fails, and therefore DistributedUpdateProcessor does not
report back the errors at all. Therefore I made the hack to pick up the
exceptions at StreamingSolrServers-level so that I, in SecurityDistributedTest,
can actually assert that both inner requests fail. I do not know if there is
more to report - I expect, because of the "// TODO - we may need to tell about
more than one error..." comment, that this has already been reported. It is a
little hard to fix, because you need to create an infrastructure that is able
to report back multiple errors to the client. We already have that in our
version of Solr (created that infrastructure when we implemented optimistic
locking, in order to be able to get e.g. 3 version-conflict-errors back when
sending a multiple-document-update including 10 documents for update, where 3
failed and 7 succeeded), but it is a long time since we handed it over to
Apache Solr (see SOLR-3382). I guess there is nothing left to report - I have
no problem that you just delete this FIXME
> 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: 5.0
>
> 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.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
