[
https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14234132#comment-14234132
]
Shai Erera commented on SOLR-4470:
----------------------------------
Hi Per. I've skimmed briefly through the history of this issue, but didn't read
it thoroughly. I noticed that some of the comments were around the size of the
patch. I tend to agree with such comments in general, although sometimes a
patch just needs to be big. Reviewing the patch _very_ briefly, I noticed that
there are many changes due to the addition of authCredentials to SolrServer API
methods (I counted around 600+ lines in the patch, which is ~10%). I have few
questions about that:
* Is it correct that every SolrServer can handle authCredentials? And not e.g.
only HttpSolrServer.
* Is it mandatory to nearly double the API with this extra parameter? I guess
this is a general question about usability of the update API. We could probably
refactor things to look more friendly, e.g. introduce an UpdateRequest with
fluid interface, something like:
{{UpdateRequest.add().doc(doc).commitWithin(-1).authCredentials(creds)}}. Then
SolrServer would just have a single .execute() method which takes an
UpdateRequest and processes it.
** This change is unrelated to this issue, but if we do this separately, it
might simplify this patch a bit.
** Even without refactoring though, I wonder if we cannot just tell people who
need to set authCredentials to build and UpdateRequest themselves, since I
assume this code path won't be that common among our users. Then we don't put
the authCredentials in the face of all users.
On a personal note, even if I wanted to help you get this committed, it's
impossible for me to digest and decently review a 6300 lines patch. I think we
ought to be able to break it down into smaller manageable commits. For example,
can we add basicAuth to Solr/Cloud separately from Solrj? Yes, perhaps it will
be more usable for Solrj users, but it doesn't mean it has to go in the same
commit.
And on another note, I share your view about the need to modernize (pretty word
for 'refactoring') the Solr API, but I think it will be accepted better if we
do this piecemeal. For instance, if we want to improve SolrServer API (by
adding this fluid UpdateRequest), we can start with writing UpdateRequest2 with
the fluid API that we think it should have. We should even be able to commit it
(gradually), since at first it won't be used by the server. We then make a
series of commits (this is just an example):
# Add UpdateRequest2 with addDocuments support
# Add rollback to UpdateRequest2
# Add AuthCredentials
# Add ....
# Add SolrServer.execute(UpdateRequest2)
After everything works well and is properly tested, and especially after that
last commit, we can rip out UpdateRequest in exchange for UpdateRequest2. I
personally wish we didn't need to do all the API back-compat, but this should
be an easy change -- deprecate everything on 5x, remove on trunk and delegate
all 5x deprecated APIs to UpdateRequest2. BTW, I don't propose to stick w/
UpdateRequest2, it's just an example :).
Not that I expect you to do all this, but I think if e.g. the API looked like
that, then adding authCredentials to Solrj would be much easier, and looked
'cleaner'.
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
