lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Høydahl (JIRA) <j...@apache.org>
Subject [jira] [Commented] (SOLR-4470) Support for basic http auth in internal solr requests
Date Wed, 06 Mar 2013 13:26:13 GMT

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


Mime
View raw message