[
https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13671249#comment-13671249
]
Per Steffensen commented on SOLR-4470:
--------------------------------------
{quote}
just skimming the patch... it looks like it adds:
METHOD.GET, SEARCH_CREDENTIALS
to every request.
{quote}
Seems like you have been skimming test-code. METHOD.GET is not something you
add - its where you decide which http-method to use. That was implicit before,
but explicit now, simple because I wanted to introduce a credetials-parameter
to many of the request-helper-methods, and choose to add it only as the last
parameter to the existing variant that had the highest number of params. It
results in a lot of repetitions of the same parameters for those
request-helper-methods in test-code, but the alternative to me was to make
major refactoring/cleanup in this area and it really isnt in scope. It ought to
be cleaned up a little, though. But is always did - both before and after this
patch.
bq. ... and adding plugin support in solr.xml for plugging in your own
internalRequestFactory and subRequestFactory.
Nice!
But what happened to small steps? I deliberately did not do things like that to
keep first step as small as possible
bq. Next, will explore Ryan McKinley's proposal for enforcing invariant params
through TestHttpSolrServer
Credentials are not (Solr-)params, and if you want "forward from super-request"
they are not even "invariant". Besides that you need to be able to control
which credentials to use from outside the Solr-node (in a kind of config) - and
you probably also want to be able to control the "strategy".
bq. ... its code a user can plug in as a filter himself and be responsible for
himself
It was that all along. Now we just make it a little harder for him to "borrow"
the filter. But Ok for me - it is only a very peripheral thing, and not
important to the essence of the patch or this issue.
> 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: 4.4
>
> Attachments: SOLR-4470_branch_4x_r1452629.patch,
> SOLR-4470_branch_4x_r1452629.patch, SOLR-4470_branch_4x_r1454444.patch,
> SOLR-4470.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: [email protected]
For additional commands, e-mail: [email protected]
