[ https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13933081#comment-13933081 ]
Jan Høydahl edited comment on SOLR-4470 at 3/13/14 11:45 AM: ------------------------------------------------------------- bq. Guess this should not be a TODO here since we're inside the SysProp impl I moved the meat of the comment as a JavaDoc on the class itself. bq. I found no way to test if a Set is unmodifiable Try to modify it and catch UnsupportedOperationException :-) However I find no harm in always wrapping, so I'll just remove the TODO. bq. Thread.sleep(10000); Since collection API since SOLR-4577 already waits for completion, the 10s sleep can go away right away, and when SOLR-5853 is done, we can also do an extra assert on the response. *Comments wanted* Any comments on the {{doAndAssertSolrExeption(-1 /*403*/...}} part or the dead code snippet? Other changes I'm doing in the next version of the patch: * Moving the solr.xml factory-class config from {{solr/security/insanely-long-and-complicated-tagname/xxxRequest...}} to: {{solr/authentication/subRequestFactory/str\[@name='class'\]}}, this way it is possible to remember the path :-) *Edit: keep it on top level since auth may be wanted outside of solrcloud as well, e.g. replicationHandler* * Simplifying the basic auth sysProperty names from {{internalAuthCredentialsBasicAuthUsername}} and {{internalAuthCredentialsBasicAuthPassword}} to {{solr.auth.user}} and {{solr.auth.pass}} * Randomizing BaseDistributedSearchTestCase.RUN_WITH_COMMON_SECURITY in \@BeforeClass, but it will of course still always be active for the tests in SecurityDistributedTest was (Author: janhoy): bq. Guess this should not be a TODO here since we're inside the SysProp impl I moved the meat of the comment as a JavaDoc on the class itself. bq. I found no way to test if a Set is unmodifiable Try to modify it and catch UnsupportedOperationException :-) However I find no harm in always wrapping, so I'll just remove the TODO. bq. Thread.sleep(10000); Since collection API since SOLR-4577 already waits for completion, the 10s sleep can go away right away, and when SOLR-5853 is done, we can also do an extra assert on the response. *Comments wanted* Any comments on the {{doAndAssertSolrExeption(-1 /*403*/...}} part or the dead code snippet? Other changes I'm doing in the next version of the patch: * Moving the solr.xml factory-class config from {{solr/security/insanely-long-and-complicated-tagname/xxxRequest...}} to below solrcloud: {{solr/solrcloud/auth/subRequestFactory/str\[@name='class'\]}}, this way it is possible to remember the path :-) * Simplifying the basic auth sysProperty names from {{internalAuthCredentialsBasicAuthUsername}} and {{internalAuthCredentialsBasicAuthPassword}} to {{solr.auth.user}} and {{solr.auth.pass}} * Randomizing BaseDistributedSearchTestCase.RUN_WITH_COMMON_SECURITY in \@BeforeClass, but it will of course still always be active for the tests in SecurityDistributedTest > 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: 5.0 > > Attachments: SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, > SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, > SOLR-4470.patch, SOLR-4470_branch_4x_r1452629.patch, > SOLR-4470_branch_4x_r1452629.patch, SOLR-4470_branch_4x_r1454444.patch, > SOLR-4470_trunk_r1568857.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.2#6252) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org