Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Date: Mon, 27 Jan 2014 18:25:50 +0000 (UTC)
From: "Shawn Heisey (JIRA)" <jira@apache.org>
To: dev@lucene.apache.org
Message-ID: <JIRA.12632802.1361178521555.19466.1390847150149@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=3D13883=
053#comment-13883053 ]=20

Shawn Heisey commented on SOLR-4470:
------------------------------------

bq. This product does not, and even worse, the core Dev team seems intent o=
n NEVER doing so!

I don't know that we *never* intend on adding security.  We face a major pr=
oblem with doing so at this time, though:  We have absolutely no idea what =
servlet container the user is going to use for running the solr war.  The e=
xample includes jetty, but aside from a few small edits in the stock config=
 file, it is unmodified.  Solr has no control over the server-side HTTP lay=
er right now, so anything we try to do will almost certainly be wrong as so=
on as the user changes containers or decides to modify their container conf=
ig.

Solr 5.0 will not ship as a .war file.  The work hasn't yet been done that =
will turn it into an actual application, but it will be done before 5.0 get=
s released.  Once Solr is a "real" application that owns and fully controls=
 the HTTP layer, security will not be such a nightmare.  You mention Elasti=
cSearch and its ability to deal with security.  ES is already a standalone =
application, which means they can do a lot of things that Solr currently ca=
n't.  It's a legitimate complaint with Solr, one that we are trying to rect=
ify.

bq. Also, Mavenize the damned thing! Modern projects still use Ant? I haven=
't opened a build.xml script in half a decade or more....

I can't say anything about maven vs. ant.  I don't have enough experience w=
ith either.


> 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
>            Assignee: Jan H=C3=B8ydahl
>              Labels: authentication, https, solrclient, solrcloud, ssl
>             Fix For: 4.7
>
>         Attachments: SOLR-4470.patch, SOLR-4470.patch, SOLR-4470_branch_4=
x_r1452629.patch, SOLR-4470_branch_4x_r1452629.patch, SOLR-4470_branch_4x_r=
1454444.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 was sent by Atlassian JIRA
(v6.1.5#6160)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org