[
https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13594817#comment-13594817
]
Per Steffensen commented on SOLR-4470:
--------------------------------------
Added a few (well a lot) words to http://wiki.apache.org/solr/SolrSecurity.
Both elaborating on setting up and using security in general, but also how my
patch will change things. The "with SOLR-4470" and "without SOLR-4470" parts
can be removed when/if the patch gets committed. Please do not delete the
SOLR-4470 related descriptions, because someone might want to use and
understand what the patch does for you, even though it is never committed.
bq. Please read the Do's and Don'ts in
http://wiki.apache.org/solr/HowToContribute#Creating_the_patch_file
I did, but just because things are mentioned there, it does not make them less
"bad" or "good". Actually I am trying to change the "rules" there and in the
minds of committers in general
bq. 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.
I understand and agree that this is a valid downside of big patches, but the
alternative apparently is that refactoring is not done - enough.
bq. There are many examples of patches in the past doing only refactoring or
only formatting changes
Glad to hear that this happens. But apparently not enough - look at the code! -
structure, reparation of concerns, etc.
bq. Also, if a change is considered major or risky we have historically started
in a branch
That is a nice strategy, and my patch might be considered major or risky to
some. I am completely in on the branch thingy. You are very welcome to branch
and add the patch - let me know if I can help in any way. I just fear that it
will sit on the branch and rot - and basically I do not care where the patch
rots :-) I am interested in getting it committed and used in a future release,
so that others can benefit, and so that there is less potential merging
conflicts when we want to upgrade our "local version of Solr" (which includes
this patch, because we need it in production) to include new code from Apache
Solr.
bq. 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
I would like to, but I do not want to put in the work as long as I fear that no
one want to work with me, no matter what I do. I didnt ask for a promise, but
just an indication that some committer (at least at the time being) has the
intention to participate.
And this way of working will make it a very big and long-term process to get in
the complete patch. I am not hired to work on Solr, but to deliver a product to
a customer, a product which happens to be based on Solr. I can do a perfectly
nice piece of work introducing this feature in a week or two, for it to be used
in our application. My customer is glad to pay me doing that, but he does not
understand how I can make the change in a week or two, see it work in
production, but that I have to use half a year getting it in at Apache Solr -
they ought to be happy that we already contributed a few weeks of work to
introduce a feature that works, he thinks.
bq. So a first suggestion for one thing you could start with is factoring out
the fix for the PeerSync.close issue into an own patch and get that committed,
since it is a side-issue.
I might do that, but its only a few lines, and will only reduce the patch a few
percent, so not even you believe that will make a difference :-)
> 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
