lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Høydahl (JIRA) <>
Subject [jira] [Commented] (SOLR-4470) Support for basic http auth in internal solr requests
Date Thu, 07 Mar 2013 10:16:13 GMT


Jan Høydahl commented on SOLR-4470:

bq. It would be ok for me to change the syntax into JSON, or maybe support both, but that
ought to be another improvement-jira.


bq. Primarily I added them because those methods are used a lot from testing-code where I
want to provide credentials

Hmm, perhaps make the new convenience methods protected to avoid public use and keep test
code nice (if tests are in same pkg). Then we don't commit to supporting a new API right now
and we can decide later how or whether to refactor this.

Is it ok for you to continue on the trunk patch from now? The alternative is to make one for
branch_4x. It's pros and cons. Maybe a branch_4x patch will attract more 4.1 users to try
it out in their existing dev/test envs? What do others say?
> 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
>              Labels: authentication, https, solrclient, solrcloud, ssl
>             Fix For: 4.2, 5.0
>         Attachments: SOLR-4470_branch_4x_r1452629.patch, SOLR-4470_branch_4x_r1452629.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 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