[
https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13934922#comment-13934922
]
Jan Høydahl commented on SOLR-4470:
-----------------------------------
A new version of the patch is uploaded, fits with current trunk r1577444
Changes in addition to the ones mentioned above:
* Removed 10s sleep and assert on return value from createCollection
(SOLR-5853) - tests pass
* Re-enabled dead code {{controlClient.query(getParams, METHOD.GET,
SEARCH_CREDENTIALS);}} - tests pass!
* Renamed {{MyConcurrentUpdateSolrServer}} to
{{ErrorHandlingConcurrentUpdateSolrServer}}
* Changed to using diamonds {{<>}} in the patch to align with recent changes in
trunk
Currently having a discussion in SOLR-5220 to fix return of true error from
{{LBHttpSolrServer}}, but that should not hold up this patch.
We should create JIRA's for the two remaining FIXME's in the patch
({{SolrCmdDistributor}}) and replace the comment with a reference to the JIRA,
[~steff1193] perhaps you already filed these two?:
{code}
// 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
{code}
and
{code}
server = currentSolrServerFactory.createNewClient(url, httpClient, 100, 1,
updateExecutor, true,
req, // FIXME Giving it the req here to use for created errors will not
work, because this reg will
// be used on errors for all future requests sent to the same URL.
Resulting in this first req
// for this URL to be resubmitted in
SolrCmdDistributor.doRetriesIfNeeded when subsequent
// different requests for the same URL fail
errors);
{code}
> 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_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]
