[
https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13883053#comment-13883053
]
Shawn Heisey commented on SOLR-4470:
------------------------------------
bq. This product does not, and even worse, the core Dev team seems intent on
NEVER doing so!
I don't know that we *never* intend on adding security. We face a major
problem 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
example 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 layer
right now, so anything we try to do will almost certainly be wrong as soon as
the user changes containers or decides to modify their container config.
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 gets
released. Once Solr is a "real" application that owns and fully controls the
HTTP layer, security will not be such a nightmare. You mention ElasticSearch
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 can't. It's a
legitimate complaint with Solr, one that we are trying to rectify.
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 with
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), SolrCloud
> Affects Versions: 4.0
> Reporter: Per Steffensen
> Assignee: Jan Høydahl
> Labels: authentication, https, solrclient, solrcloud, ssl
> Fix For: 4.7
>
> Attachments: SOLR-4470.patch, SOLR-4470.patch,
> SOLR-4470_branch_4x_r1452629.patch, SOLR-4470_branch_4x_r1452629.patch,
> SOLR-4470_branch_4x_r1454444.patch
>
>
> 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 was sent by Atlassian JIRA
(v6.1.5#6160)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
