[
https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13595842#comment-13595842
]
Per Steffensen commented on SOLR-4470:
--------------------------------------
bq. Hmm, perhaps make the new convenience methods protected to avoid public use
and keep test code nice (if tests are in same pkg)
They are not in the same package. SolrServers are in
"org.apache.solr.client.solrj.xxx" packages, while tests inheriting from
BaseDistributedSearchTestCase are (mostly) in "org.apache.solr" or
"org.apache.solr.cloud". We could make them protected and then make a
TestSolrServerWrapper (in package "org.apache.solr.client.solrj"), which makes
them public, and then use TestSolrServerWrapper across tests (inheriting from
BaseDistributedSearchTestCase). It is basically a question of changing
"clients" and "downedClients" in BaseDistributedSearchTestCase to be a list of
TestSolrServerWrapper instead of SolrServer. And do the same for
commondCloudSolrServer.
bq. Is it ok for you to continue on the trunk patch from now? 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?
I would prefer branch_4x, because
* I see not problem just getting it in, because I am so sure it does not break
anything - at least as long as you do not setup security, and in practice you
where not able to before anyway.
* Our Solr release is currently based on a Apache Solr 4.0 and we probably want
to upgrade to be based on another 4.x before going to 5.x, and if this patch is
in the 4.x version we upgrade to be based on, I will not have to deal with
merging it in. Of course that is a personal argument :-)
But whatever the community can accept and a committer is willing to do, I will
have to live with. Ordered preferences: branch_4x, trunk, security (the new
branch), nowhere at all :-)
bq. The alternative is to make one for branch_4x
We already have a branch_4x patch - the one I provided!??!
> 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
> 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, SOLR-4470.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: [email protected]
For additional commands, e-mail: [email protected]
