[
https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13664193#comment-13664193
]
Per Steffensen commented on SOLR-4470:
--------------------------------------
bq. I'm wondering if all the people who reported that they are using this
patch/feature need that "forwarding of original credentials with a
subrequests"? What are the common use cases for this?
The reasoning is that, in general you do not want a user to be able to have
something done (by the subrequest) for him, that we was not allowed to do
directly himself - forwarding credentials will ensure that. I do not know if
that is what "everybody" wants, but to me it seems like a nice default
behaviour. This is only current/default behaviour. The code if nicely
structured so that it is prepared for pluggable "subrequest credentials
strategy". You need to have
InterSolrNodeAuthCredentialsFactory.setCurrentSubRequestFactory called to
change the strategy/behaviour. It is currently not possible to change the
strategy from "the outside" through configuration, but it can easily be exposed
- because the code it prepared for it.
If you are willing to hack a little, I guess it is possible to add you own
little servlet "MyStrategyChangingServlet" (to web.xml), make sure to add
<load-on-startup> and make a call to
InterSolrNodeAuthCredentialsFactory.setCurrentSubRequestFactory(SubRequestFactory)
in MyStrategyChangingServlet.init() :-) If you want the behaviour to be "just
always use a fixed set of credentials", you can find inspiration on how to code
your special SubRequestFactory, by looking at how the
InterSolrNodeAuthCredentialsFactory.DefaultInternalRequestFactory works - that
is the default implementation for getting credentials for inter-solr-requests
that is NOT a direct/synchronous consequence of "super"-request from "the
outside".
> 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]
