Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Date: Thu, 7 Mar 2013 10:16:13 +0000 (UTC)
From: =?utf-8?Q?Jan_H=C3=B8ydahl_=28JIRA=29?= <jira@apache.org>
To: dev@lucene.apache.org
Message-ID: <JIRA.12632802.1361178521555.398696.1362651373550@arcas>
In-Reply-To: <JIRA.12632802.1361178521555@arcas>
References: <JIRA.12632802.1361178521555@arcas>
Subject: [jira] [Commented] (SOLR-4470) Support for basic http auth in
 internal solr requests
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/SOLR-4470?page=3Dcom.atlassian.=
jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D13595=
742#comment-13595742 ]=20

Jan H=C3=B8ydahl commented on SOLR-4470:
-----------------------------------

bq. It would be ok for me to change the syntax into JSON, or maybe support =
both, but that ought to be another improvement-jira.

Sure

bq. Primarily I added them because those methods are used a lot from testin=
g-code where I want to provide credentials

Hmm, perhaps make the new convenience methods protected to avoid public use=
 and keep test code nice (if tests are in same pkg). Then we don't commit t=
o supporting a new API right now and we can decide later how or whether to =
refactor this.

Is it ok for you to continue on the trunk patch from now? The alternative i=
s to make one for branch_4x. It's pros and cons. Maybe a branch_4x patch wi=
ll attract more 4.1 users to try it out in their existing dev/test envs? Wh=
at do others say?
               =20
> 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), SolrC=
loud
>    Affects Versions: 4.0
>            Reporter: Per Steffensen
>              Labels: authentication, https, solrclient, solrcloud, ssl
>             Fix For: 4.2, 5.0
>
>         Attachments: SOLR-4470_branch_4x_r1452629.patch, SOLR-4470_branch=
_4x_r1452629.patch, SOLR-4470.patch
>
>
> We want to protect any HTTP-resource (url). We want to require credential=
s 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 he=
re 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 "forw=
arded" when a request directly/synchronously trigger a subrequest, and fall=
back 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 w=
ould 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. d=
igest)
> We will work at a solution but create this JIRA issue early in order to g=
et 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 administrato=
rs
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