[ 
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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to