[
https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13667712#comment-13667712
]
Jan Høydahl edited comment on SOLR-4470 at 5/27/13 12:02 PM:
-------------------------------------------------------------
bq. JVM params is the simplest way to control which implementations to be used
behind the interfaces. That is, in my opinion, what should have been included
here. Going from control through JVM params and adding support for control
through solr.xml or something else should be another issue, but it is certainly
a good and valid idea.
The way we normally set up {{solr.xml}} configs is with
<mytag>$\{my.jvm.param\}</mytag> style, so admin can choose whether to pass the
option as JVM param or include it in solr.xml directly. Something like
{code:xml}
<solr>
...
<subRequestFactory class="${solr.subRequestFactory}" />
<internalRequestFactory class="${solr.internalRequestFactory}" />
</solr>
{code}
Regarding [~markrmil...@gmail.com]'s concern with authorization "creep", I to
some extent agree. But since, as you say, this is test-code only, let's move
the class {{RegExpAuthorizationFilter}} from runtime codebase and into the test
framework. In that way, it is clear that it is only used for realistic test
coverage. And if anyone wishes to setup a similar setup in their production
they may borrow code from the test class, but it will be a manual step
reinforcing that this is not a supported feature of the project as such.
was (Author: janhoy):
bq. JVM params is the simplest way to control which implementations to be
used behind the interfaces. That is, in my opinion, what should have been
included here. Going from control through JVM params and adding support for
control through solr.xml or something else should be another issue, but it is
certainly a good and valid idea.
The way we normally set up {{solr.xml}} configs is with
<mytag>$\{my.jvm.param\}</mytag> style, so admin can choose whether to pass the
option as JVM param or include it in solr.xml directly. Something like
{code:xml}
<solr>
...
<subRequestFactory class="${solr.subRequestFactory}" />
<internalRequestFactory class="${solr.internalRequestFactory}" />
</solr>
{code}
Regarding [~markrmil...@gmail.com]'s concern with authorization "creep", I to
some extent agree. But since, as you say, this is test-code only, let's move
the class {{RegExpAuthorizationFilter}} from runtime codebase and into the test
framework. In that way, it is clear that it is only used for realistic test
coverage. And if anyone wishes to setup a similar setup in their production
they may borrow code from the test class, but it will be a manual step
reinforcing that this is not something that the project *supports* - but *if*
someone sets up this in the container,
> 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.4
>
> Attachments: SOLR-4470_branch_4x_r1452629.patch,
> SOLR-4470_branch_4x_r1452629.patch, SOLR-4470_branch_4x_r1454444.patch,
> SOLR-4470.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 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
