[
https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13594697#comment-13594697
]
Jan Høydahl commented on SOLR-4470:
-----------------------------------
bq. It is like you are not allowed to do natural refactoring because it make a
patch bigger than the absolute minimum to introduce the new feature.
Please read the Do's and Don'ts in
http://wiki.apache.org/solr/HowToContribute#Creating_the_patch_file
It's not about forbidding this or that, it's just that if a single patch
touches too much, history shows that it is hard to maintain and relate to for
all the different persons, both committers and contributors. So cohesion
matters. There are many examples of patches in the past doing only refactoring
or only formatting changes. Those are welcome too, but it tends to be more
efficient to first check in an API change which is necessary for a new feature,
and then check in the core parts of that feature, and later check in the rest.
Also, if a change is considered major or risky we have historically started in
a branch, then when mature merged in to trunk, then let it bake with nightly
builds and other feedback for a few months before back-porting to the current
stable branch. Chances are we'd want something similar here too, and that's why
I suggested a branch off of trunk to start with.
Rather than trying to book a certain committer up-front to promise to work on
the code you should incrementally continue work on it yourself, listening to
feedback, rework the patch/branch... It's more likely to attract a committer
helping with the last mile of something which is obviously being in the makings
and being improved for a long time, than up-front commitments.
My 2¢
> 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: Bug
> Components: clients - java, multicore, replication (java), SolrCloud
> Affects Versions: 4.0
> Reporter: Per Steffensen
> Labels: authentication, solrclient, solrcloud
> Fix For: 4.2
>
> Attachments: SOLR-4470_branch_4x_r1452629.patch,
> SOLR-4470_branch_4x_r1452629.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
