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 Sat, 23 Feb 2013 11:28:13 GMT


Per Steffensen commented on SOLR-4470:

Prepare for a new feature well covered by test with the following testing strategy
* 1) We run with "a common security setup" in most (all tests inheriting from BaseDistributedSearchTestCase)
distributed/cloud tests
* 2) There will be a new distributed/cloud test focusing on error-scenarios around security
- authentication/authorization errors when you do not provide correct credentials

I chose 1) because
* I believe it is the easiest/best way to make sure support for A&A is correct in all
inter-solr-node communication 
* It would increase time-to-run-test-suite a lot if I was going to introduce new A&A focused
tests for all inter-solr-node communications (search/update/get-sub-requests, collection-API-sub-requests,
recovery-sub-request etc.)
* If we introduce a new feature requiring new inter-solr-node communication it is likely that
it will inherit from BaseDistributedSearchTestCase (including security setup out-of-the-box),
and therefore "remind" the developer to remember to provide correct credentials for the inter-solr-node
requests involved.

I added 2) because we with 1) will have good coverage of cases where you provide "good" credentials
in inter-solr-node communication, but the reason it works might be because security was somehow
not enabled or working correctly. Therefore added error-scenarios making sure security is
enabled and working, by asserting on authentication/authorization errors when you provide
"bad or none" credentials.

"Common security scheme" being
* A search-user that is only allowed to do selects/gets
* An update-user that is only allowed to do updates
* An all/admin-user that is allowed to do everything
* You are not allowed to do anything without providing credentials

> 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