lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Per Steffensen (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (SOLR-4470) Support for basic http auth in internal solr requests
Date Mon, 18 Feb 2013 11:23:12 GMT

    [ https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13580512#comment-13580512
] 

Per Steffensen edited comment on SOLR-4470 at 2/18/13 11:21 AM:
----------------------------------------------------------------

First idea was to put "internal credentials" in solrconfig.xml, but solrconfig.xml is part
of a configuration of one or more replica/shards/collections, and the "internal credentials"
really should not be "per shard" but "per node" or "per cluster". Guess "per node" could be
implemented as either "put in solr.xml" or "give as VM-params", but I dont know if there are
future plans on getting rid of solr.xml. "Per cluster" could be implemented by "put in ZK
(at a global location)". This will of course raise another issue of protecting access to solr.xml
or ZK, but that is already relevant as it is today. We have an upcoming US focusing on protecting
stuff in ZK, so we plan to deal with that part. Files can be protected in misc ways based
on the OS.

Opinions from the community please:
* solr.xml?
* "global" location in ZK?
* or, do you think this is a solrconfig.xml thingy?
                
      was (Author: steff1193):
    First idea was to put "internal credentials" in solrconfig.xml, but solrconfig.xml is
part of a configuration of one or more replica/shards/collections, and the "internal credentials"
really should not be "per shard" but "per node" or "per cluster". Guess "per node" be implemented
as either "put in solr.xml" or "give as VM-params", but I dont know if there are future plans
on getting rid of solr.xml. "Per cluster" could be implemented by "put in ZK (at a global
location)". This will of course raise another issue of protecting access to solr.xml or ZK.
We have an upcoming US focusing on protecting stuff in ZK, so we plan to deal with that part.
Files can be protected in misc ways based on the OS.

Opinions from the community please:
* solr.xml?
* "global" location in ZK?
* or, do you think this is a solrconfig.xml thingy?
                  
> 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message