[
https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13582144#comment-13582144
]
Per Steffensen edited comment on SOLR-4470 at 2/20/13 1:29 PM:
---------------------------------------------------------------
I think you should be able to specify credentials both on SolrServer-level (all
requests made through this will have the same credentials added) and on
SolrRequest-level (so that you can use the same SolrServer for sending requests
with different credentials). I added a credentials-field on SolrRequest and it
is all fine if you create the SolrRequest object "yourself", but unfortunately
there are a set of "helper"-methods on SolrServer that basically create the
SolrRequest object for you without giving you a change to modify it afterwards.
How do we prefer to "hand over" credentials for those SolrRequests? Ideas on
the top of my head:
* 1) Add a credentials-param to all the "helper"-methods (maybe make two
versions of each method - one that do and one that does not take a credentials
object)
* 2) Change SolrRequest constructor so that it supports reading credentials
from a threadlocal, that you will need to set before calling one of the
"helper"-methods (instead of providing it as a parameter to the "helper"-method)
I wouldnt want to do 1) before agreed by the community, and 2) is kinda hacky
(even though I like to use threadlocals a lot more than what the average
developer seem to do). It seems like 1) was used back when "commitWithinMs" was
added, but maybe it is not the way to continue - we will end up with huge set
of similar (except for parameter differences) "helper"-methods. Actually I
would have preferred that "commitWithinMs" was never made this way - maybe one
should have foreseen that this is not the last parameter you want to be able to
give to the "helper"-methods in general, so maybe back then you should have
introduced a callback-thingy instead of the "commitWithinMs"-parameter - a
callback-thingy that could be used for modifying the SolrRequest object after
it had been set up by the "helper"-method.
* 3) Of course that is also an option now, but then we should really get rid of
"commitWithinMs" and that will break API backwards compatibility.
was (Author: steff1193):
I think you should be able to specify credentials both on SolrServer-level
(all requests made through this will have the same credentials added) and on
SolrRequest-level (so that you can use the same SolrServer for sending requests
with different credentials). I added a credentials-field on SolrRequest and it
is all fine if you create the SolrRequest object "yourself", but unfortunately
there are a set of "helper"-methods on SolrServer that basically create the
SolrRequest object for you without giving you a change to modify it afterwards.
How do we prefer to "hand over" credentials for those SolrRequests? Ideas on
the top of my head:
* 1) Add a credentials-param to all the "helper"-methods (maybe make two
versions of each method - one that do and one that does not take a credentials
object)
* 2) Change SolrRequest constructor so that it supports reading credentials
from a threadlocal, that you will need to set before calling one of the
"helper"-methods (instead of providing it as a parameter to the "helper"-method)
I wouldnt want to do 1) before agreed by the community, and 2) is kinda hacky
(even though I like to use threadlocals a lot more than what the average
developer seem to do). It seems like 1) was used back when "commitWithinMs" was
added, but maybe it is not the way to continue - we will end up with huge set
of similar (except for parameter differences) "helper"-methods. Actually I
would have preferred that "commitWithinMs" was never made this way - maybe one
should have foreseen that this is not the last parameter you want to be able to
give to the "helper"-methods in general
3) Maybe back then you should have introduced a callback-thingy instead of the
"commitWithinMs"-parameter that could be used for modifying the SolrRequest
object after it had been set up by the "helper"-method
Of course 3) would also be an option now, but then we should really get rid of
"commitWithinMs" and that will break API backwards compatibility.
> 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
>
>
> 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]
