[ https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13583030#comment-13583030 ]
Per Steffensen edited comment on SOLR-4470 at 2/21/13 9:17 AM: --------------------------------------------------------------- bq. then put a programmable proxy in front of Solr, like Varnish or something Uhhh, I think that is too much to require for doing faily simple authorization. And depending on where you put Varnish the authorization might not be preformed on solr-to-solr requests, and one of the focus points here is to make sure it is, because we basically do not want to make it possible to have a solr-to-solr request R2 performed as a direct reaction to a request R1 comming from "the outside", where the "outside user" is authorized to do R1 but not to do R2. But I guess it can fairly easy be done using a filter, and I will put up a description on Wiki on how to do it. We are going to do it anyway in my project. was (Author: steff1193): bq. then put a programmable proxy in front of Solr, like Varnish or something Uhhh, I think that is too much to require for doing faily simple authorization. And depending on where you put Varnish the authorization might not be preformed on solr-to-solr requests, and one of the focus points here is to make sure it is, because we basically do not want to make it possible to have a solr-to-solr request R2 performed as a direct reaction to a request R1 comming from "the outside", where the "outside user" is authorized to do R1 but not to do R2. > 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org