[ 
https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13673752#comment-13673752
 ] 

Mark Miller commented on SOLR-4470:
-----------------------------------

bq. always was your (single) issue with this patch, I am going to laugh my ass 
off. You clearly never looked into it, never understood it and never wanted to 
understand it - maybe until a few days ago (Im not sure).

No - it's not the single issue that I have - but it is the issue that would 
cause me to -1 the patch. Given that some other committers have expressed some 
support, it's my attempt to work with them in turning this patch into something 
I am willing to accept - not neccessarily something I want as part of the code 
base. That's why I say it makes it less contraversial - it doesn't make me 
happy with this issue, but it's a path towards me not vetoing this issue.

IMO, all this security should be handled above Solr - I don't support this 
patch. That in itself will not stop it from getting in though.

bq. I also don't agree that fixing an issue like this commits the Solr Project 
to being on the hook for security, either.

I disagree with you - once we start adding code to deal with roles or 
authorization or anything of the kind, that puts us on the hook - thats just 
how it is and why we don't have code like that.

The code to faciliate passing internode auth - while not something I'm 
interested in - is not what puts us on the hook regarding security and Solr 
code.

                
> 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.4
>
>         Attachments: SOLR-4470_branch_4x_r1452629.patch, 
> SOLR-4470_branch_4x_r1452629.patch, SOLR-4470_branch_4x_r1454444.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