[
https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13594887#comment-13594887
]
Jan Høydahl commented on SOLR-4470:
-----------------------------------
bq. I might do that, but its only a few lines, and will only reduce the patch a
few percent, so not even you believe that will make a difference
Actually, the reason I comment at all is that I'm fairly interested in this
feature myself on behalf of a few customers, so I'd love to see it succeed, but
right now this is too big for my time and priorities to follow through all the
way. If it were split in 3 I could probably take one of them.
Back to discussing the architecture here:
To me the approach taken looks sane and not too intrusive.
Even if solr.xml is going away, I think it would make sense to include username
& password config options in solr.xml as an alternative to passing them as
JAVA_OPTS. You'll quickly see how that is done, and using ${var} syntax with
fallback to a pre-defined default, you can choose whether to supply them as
JAVA_OPTS or directly in solr.xml. The solr.xml approach would be less
controversial to some I guess. Once solr.xml is nuked, the params will be moved
to whatever takes its place.
> 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: Bug
> Components: clients - java, multicore, replication (java), SolrCloud
> Affects Versions: 4.0
> Reporter: Per Steffensen
> Labels: authentication, solrclient, solrcloud
> Fix For: 4.2
>
> 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
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
