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, 18 Feb 2013 16:41:12 GMT


Per Steffensen commented on SOLR-4470:

bq. Acording to HTTP-URL syntax, you can give the basic auth params using http://user:password@host:port/.
As Solr is using Commons-Httpsclient for connections, wouldnt this work automatically if you
configure the node's HTTP adress using this syntax?

This is a way to specify the credentials, yes. But it can be done in other ways and is already
done in other ways in the code - see HttpClientUtil.setBasicAuth (have to say that I am currently
looking at 4.0 code, but guess it hasnt changed). The problem is not so much setting the credentials
for the internal request, but to figure out which credentials to use.
As I described above I would like the credentials for requests issued by Solr-nodes themselves,
to be copied from the originals super-request in cases where such exist - e.g. for search
and update. For some of the requests that Solr-nodes issue themselves there are no such super-request
(e.g. for sync stuff) and for other requests the sub-requests are issued asynchronously from
its super-request (e.g. replica-creation-request are issued asynchronously from a create request
to the Collection API). For both such kind of request we need some credentials to include.
Thats where configuring "internal credentials" is needed.

If you where thinking about actually writing URLs like "http://user:password@host:port/" in
ZK, that is not going to work, since username/password is not (necessarily) static per target-node,
since I want to "forward" whatever credentials are given for sub-requests triggered synchronously
by super-requests (e.g. search and update) whereas "internal credentials" will be used when
there is no such super-request (sync stuff) or when there is an asynchronous border between
it and the sub-requests (e.g. Collection API operations).

Very concrete in our usage of Solr, we (for now) would like to have two users
* Admin-user which is allowed to do everything
* Search-user which is only allowed to search
We will configure solr-nodes with the "Admin-user credentials" as "internal credentials".
So they will be used for replica-creation and sync stuff. But "outside users" of our application
we only be given the Search-user credentials, and we want to make sure that they are not allowed
to do anything but search. It is not cool if a request made with the Search-user credentials
results in sub-requests with Admin-user credentials.

Hope it makes a little bit of sense, of else I hope it will when I provide some code. I will
post patch soon with early version of my work.
> 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