[
https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14234220#comment-14234220
]
Shai Erera commented on SOLR-4470:
----------------------------------
bq. No. Actually I thought Jan Høydahl removed the added API methods
Hmm, I downloaded the latest SOLR-4470.patch, which seems to be the latest of
all other patches too, dating 14/Mar/14.
bq. I think you are focusing too much on the API changes, though. It is a
fairly small part of the patch.
You're right :). But that's the first thing that caught my eyes - at least 10%
of the patch seem to be involving these API changes. So in trying to help
understand how can this patch be split into (hopefully *much*) smaller patches,
I saw this as a low hanging fruit.
When I started my way in this community, I used to think like you - I've done
some work, so let me just drop it into JIRA and get a committer to commit it.
Not because it's perfect, but because it's "mature" and "product-ready" - we
can always iterate and improve afterwards. Over the years I've learned that it
doesn't work that way - small patches require less time of a committer to
review and approve.
This is also in general how we develop software. I'm sure you didn't code all
of this in a single stroke. And I bet that in your private SVN (or whatever you
use), these changes were done over multiple commits. To you, this is one piece
of work ready to get in. To the community, it's a giant clob that will be
committed without a decent chance to review it thoroughly, and explore
alternatives. It's just too overwhelming to think about it from the start, like
we would have if you e.g. opened a JIRA and said "hey, I want to add basic-auth
to Solr, let's discuss".
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)". And then open subsequent issues to address different places of the
code that involve basic-auth. Even if this work *must* be committed as a whole
to trunk, that's fine. We'll do this work entirely in a branch, but still -
multiple issues. That way, each commit gets its proper review. When it's merged
to trunk, we're sure of the design, the tests and everything else. I didn't get
too deep into it, but I do believe that it can be done on trunk though, in baby
steps.
Remember, basic-auth can exist in the code "hidden", until we feel it's ready.
So e.g. it's OK if the first commit only adds basic-auth to UpdateRequest, then
to HttpSolrServer, then to CloudSolrServer etc ... they don't all need to
support it from the start.
> 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: [email protected]
For additional commands, e-mail: [email protected]
