I usually just apply the patch and at least IntelliJ has a way to show diffs that ignore all whiltespace. Also provides context....
FWIW On Sun, Feb 23, 2014 at 3:53 AM, Per Steffensen (JIRA) <[email protected]>wrote: > > [ > https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13909755#comment-13909755] > > Per Steffensen commented on SOLR-4470: > -------------------------------------- > > Looking at the latest patch, there seem to be a lot of diffs that is only > about replacing one kind of empty line with another kind of empty line. Not > sure it belongs here. > > > 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: 5.0 > > > > Attachments: 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.1.5#6160) > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
