[
https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14234178#comment-14234178
]
Per Steffensen commented on SOLR-4470:
--------------------------------------
bq. I noticed that some of the comments were around the size of the patch
Yes, unfortunately I have provided a significant number of features/patches
that are fairly big that never got committed.
It is not that I really want to do it this way. I would much rather, as I sense
its most often done, start out with rough half-working patches, and "design the
solution" by adding to and discussing the patches as they evolve.
Unfortunately that just does not fit very well with the way my customer expects
me to work. He tells me (in this case) "I want to protect my Solrs with
username/password on HTTP level. You have two weeks to do it". I'd better get
started. I make a solution the way I think it should be, and do not have the
time to discuss it to much with the rest of you. When I have made a working
solution to the customer, I feel obligated to at least try to give it back to
Solr - if you want to use Open Source, make sure to (try to) give back whenever
you can.
This way I end up providing a fully functional complete solution. I understand
that this is hard to grasp for you guys. But I also believe that I am often
mistaken. I am not saying that you just have to commit this without any change,
dialog or whatever. I just want you to pretend that we are in the beginning of
solving this ticket, and just look at the full solution from me as a suggestion
on how to solve it, that at least can be used starting point for a discussion
and "design process". After I have made the complete solution my customer is
happy, and then I have the time to discuss/design "the real" solution with you
guys. But it usually never gets that far - no committer really want to jump
into it. Then I just say to myself that I did my duty and forwarded my solution
to the community. If no one wants to participate I cannot do much more.
The thing about the discussion/design process is that it is very CALENDAR-time
consuming. It is not that I will spend that much actual time on it - usually
you just add a few comments, change the patch a little and wait for comments,
while you do other stuff (e.g. implementing the next feature for the customer
:-) ). So I will have the time to participate in this "after full
solution"-phase of making the "right" solution for Solr.
bq. Is it correct that every SolrServer can handle authCredentials? And not
e.g. only HttpSolrServer
Yes
bq. Is it mandatory to nearly double the API with this extra parameter?
No. Actually I thought [~janhoy] removed the added API methods
bq. UpdateRequest.add().doc(doc).commitWithin(-1).authCredentials(creds)
Yes the builder-approach is IMHO in general a much better approach compared to
having numerous methods with all combinations of parameters or having one
methods taking all parameters where "special values" (like null, -1 or
something) means that you just want default on that one. But I dont see that
done in Solr. When in Rome, I guess...
bq. Then we don't put the authCredentials in the face of all users
You are probably right
bq. I think we ought to be able to break it down into smaller manageable
commits
Yes, I am sure that can be done. Seems you have a lot of good ideas on how to
cut the cake. In regards to this particular SOLR-4470, I think you are focusing
too much on the API changes, though. It is a fairly small part of the patch. So
if we want to cut SOLR-4470 into smaller patches we need more cutting that just
"API stuff" and "the rest". But in general I like all of your ideas in this
area.
> 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]
