[
https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13668111#comment-13668111
]
Per Steffensen commented on SOLR-4470:
--------------------------------------
bq. Regarding Mark Miller'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.
RegExpAuthorizationFilter could be in test-code because it is only used for
test. As I described above (somewhere) it is just does something I believe a
lot of people might want to do - simply because Solr-URLs are kinda
upside-down. Therefore I put it in the non-test part of the code, so that
people could use it if they found it useful. And described a little about it on
http://wiki.apache.org/solr/SolrSecurity#Security_in_Solr_on_per-operation_basis.
If you do not get the point that this is something you can use if you decide to
use it and that it is really not a Solr-thing, then I agree it could be
considered creeping into dealing with security enforcement in Solr. You are
welcome to move it to test-code, but then we should change the descriptions on
http://wiki.apache.org/solr/SolrSecurity#Security_in_Solr_on_per-operation_basis.
Either remove descriptions about RegExpAuthorizationFilter or include the code
from it directly on the Wiki-page for inspiration or make a pointer to
test-code and tell that you can steel it there.
bq. I tried to move RegExpAuthorizationFilter to test scope, but there is a
compile-time dependency in JettySolrRunner method lifeCycleStarted(). Can we
refactor this piece of code into test-scope as well, e.g. by exposing some a
Filter setter on JettySolrRunner?
Isnt JettySolrRunner only used for test? Why is it not in test-scope itself?
Maybe in test-framework? We can make a funny refactor and expose a
filter-setter but it seems like a strange thing to do to let JettySolrRunner,
which is only used for test, be able to use some test-stuff. What did I miss?
> 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: [email protected]
For additional commands, e-mail: [email protected]
