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 Wed, 20 Feb 2013 12:39:13 GMT


Per Steffensen commented on SOLR-4470:

I think you should be able to specify credentials both on SolrServer-level (all requests made
through this will have the same credentials added) and on SolrRequest-level (so that you can
use the same SolrServer for sending requests with different credentials). I added a credentials-field
on SolrRequest and it is all fine if you create the SolrRequest object "yourself", but unfortunately
there are a set of "helper"-methods on SolrServer that basically create the SolrRequest object
for you without giving you a change to modify it afterwards. How do we prefer to "hand over"
credentials for those SolrRequests? Ideas on the top of my head:
* 1) Add a credentials-param to all the "helper"-methods (maybe make two versions of each
method - one that do and one that does not take a credentials object)
* 2) Change SolrRequest constructor so that it supports reading credentials from a threadlocal,
that you will need to set before calling one of the "helper"-methods (instead of providing
it as a parameter to the "helper"-method)

I wouldnt want to do 1) before agreed by the community, and 2) is kinda hacky (even though
I like to use threadlocals a lot more than what the average developer seem to do). It seems
like 1) was used back when "commitWithinMs" was added, but maybe it is not the way to continue
- we will end up with huge set of similar (except for parameter differences) "helper"-methods.
Actually I would have preferred that "commitWithinMs" was never made this way - maybe one
should have foreseen that this is not the last parameter you want to be able to give to the
"helper"-methods in general
3) Maybe back then you should have introduced a callback-thingy instead of the "commitWithinMs"-parameter
that could be used for modifying the SolrRequest object after it had been set up by the "helper"-method
Of course 3) would also be an option now, but then we should really get rid of "commitWithinMs"
and that will break API backwards compatibility.
> Support for basic http auth in internal solr requests
> -----------------------------------------------------
>                 Key: SOLR-4470
>                 URL:
>             Project: Solr
>          Issue Type: Bug
>          Components: clients - java, multicore, replication (java), SolrCloud
>    Affects Versions: 4.0
>            Reporter: Per Steffensen
>              Labels: authentication, solrclient, solrcloud
>             Fix For: 4.2
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

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

View raw message