[
https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13882832#comment-13882832
]
Per Steffensen commented on SOLR-4470:
--------------------------------------
bq. We are currently using SOLR 4.5.1 in our production environment and we
tried to setup security on a SOLR cloud configuration.
Container managed authentication and authorization I presume?
bq. I have read all the 4470 issue activity and it will be very useful for us
to be able to download the SOLR-4470_branch_4x_r1452629.patch already compiled
from some place, until the 4.7 version is released.
Guess you are looking at "Fix Version/s: 4.7" on this issue, and expect that
this means that the fix will be in 4.7. I do not believe it will -
unfortunately. So if you want the feature, you need to change the patch
yourself to fit the version of Solr you are using, or you can download code for
Solr 4.4 plus numerous improvements (including SOLR-4470) here:
https://github.com/steff1193/lucene-solr. You will have to build a Solr
distribution yourself - and maven artifacts if you need those
* Building distribution from source
{code}
<checkout>
cd solr
ant -Dversion=4.4.0.myversion clean create-package
{code}
* Building and deploying artifacts is a little more complicated. Let me know if
you need that.
*Please note* that https://github.com/steff1193/lucene-solr is only a place
where we keep our version of Lucene/Solr, including the changes we have made
which has not yet been committed in Apache Solr regi. You are free to use it,
but there is no guarantee that there will ever be a version based on a Apache
Solr version higher than 4.4. It is very likely that there will be, but no
guarantee and you never know when it will happen. Of course it is all open
source so if you really want you can fork it yourself.
> 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: New Feature
> Components: clients - java, multicore, replication (java), SolrCloud
> Affects Versions: 4.0
> Reporter: Per Steffensen
> Assignee: Jan Høydahl
> Labels: authentication, https, solrclient, solrcloud, ssl
> Fix For: 4.7
>
> Attachments: SOLR-4470.patch, SOLR-4470.patch,
> SOLR-4470_branch_4x_r1452629.patch, SOLR-4470_branch_4x_r1452629.patch,
> SOLR-4470_branch_4x_r1454444.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 was sent by Atlassian JIRA
(v6.1.5#6160)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
