lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Per Steffensen (JIRA)" <>
Subject [jira] [Commented] (SOLR-4470) Support for basic http auth in internal solr requests
Date Mon, 31 Mar 2014 10:43:23 GMT


Per Steffensen commented on SOLR-4470:

Regarding the following FIXME in SolrCmdDistributor
// 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
// 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
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:
>             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
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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message