[
https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13595347#comment-13595347
]
Jan Høydahl commented on SOLR-4470:
-----------------------------------
bq. I removed the solr.xml thing again because we not are going to use it and
it would just make the patch even bigger (and we would not like that ).
Agree, keep it simple and iterate from there
I tried to apply the patch to trunk and there were not as many mismatches as I
thought. So although I created a branch
https://svn.apache.org/repos/asf/lucene/dev/branches/security/ we may not need
to use it before we feel the need for it, as long as the patch keeps applying
well for longer periods of time. Will attach trunk patch as SOLR-4470.patch
bq. Regarding running the test-suite: If not already granted in your policy
file you need to grant "permission javax.security.auth.AuthPermission "*";" in
general or at least for the JettySolrRunner (or the anonymous
MappedLoginService in JettySolrRunner). This permission is needed in order to
be able to set up the LoginModule in JettySolrRunner (test-only)
Hmm, it took some trial & error before I understood why tests failed, then I
saw this comment and changed my java.policy file. But how can this be better
integrated with Ant so that patching java.policy for all your JDKs is not a
requirement for passing Lucene/Solr tests? I think such a requirement may be a
no-starter. Is it an alternative to simply modify Jetty's xml file instead of
doing it through API?
Regarding the use of "|" as separator in RegExpAuthorizationFilter
{code:xml}
<init-param>
<param-name>search-constraint</param-name>
<param-value>1|update-role,admin-role|^.*/update$</param-value>
</init-param>
{code}
Will it work with regexes containing "|"? Or would it be more readable (and
cool) in these JSON-times to use a small object as param-value? Then we could
keep the base object syntax for any future Filter implementations.
{noformat}
{"order": 1, "roles": ["update-role","admin-role"], "regex": "^.*/update$"}
{noformat}
> 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: Bug
> Components: clients - java, multicore, replication (java), SolrCloud
> Affects Versions: 4.0
> Reporter: Per Steffensen
> Labels: authentication, solrclient, solrcloud
> Fix For: 4.2
>
> Attachments: SOLR-4470_branch_4x_r1452629.patch,
> SOLR-4470_branch_4x_r1452629.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
