[ https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14244392#comment-14244392 ]
Per Steffensen commented on SOLR-4470: -------------------------------------- bq. So maybe one suggestion I would make is - don't give up on this patch. Use this issue as an umbrella issue for adding basic-auth to Solr. Tell us "here's the entire piece of work that I've done, now I want to do it in steps (baby steps preferred)" I am not too happy about this approach in general. I like that only fully done features get committed. If you artificially break a complete feature into small steps AND COMMIT THEM you will temporarily have partly done features. No one says that you will ever get the last parts committed. I see way to much code in Solr that really smells like "we will just do this simple hacky thing here without considering nice code-structure/design and complete features - we will complete, refactor and make it nice later" - but "later" never showed up. One example that I stumbled over just recently is SOLR-5768 - I had to clean it up in SOLR-6795, SOLR-6796, SOLR-6812 and SOLR-6813. Breaking up a complete feature including thorough testing etc. into smaller pieces will have to make us enter that area of partly done stuff. I am afraid that only half of the "subsequent issues" under the "umbrella" will never be committed. That said, I am willing to try. But I want to wait to see what SOLR-6625 brings. It might very well establish a platform for solving this SOLR-4470 much more easily. > 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: Trunk > > Attachments: SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, > SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, > SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, > SOLR-4470.patch, SOLR-4470_branch_4x_r1452629.patch, > SOLR-4470_branch_4x_r1452629.patch, SOLR-4470_branch_4x_r1454444.patch, > SOLR-4470_trunk_r1568857.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.3.4#6332) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org