[jira] [Comment Edited] (SOLR-4470) Support for basic http auth in internal solr requests

["Jan Høydahl (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13931530#comment-13931530 ] 

Jan Høydahl edited comment on SOLR-4470 at 3/12/14 11:49 AM:
-------------------------------------------------------------

([~steff1193] I did not complete my comment earlier)

Checking *TODO*s in the patch

h3. In SystemPropertiesAuthCredentialsInternalRequestFactory

bq. TODO since internalAuthCredentials is something you use for "internal" requests against other Solr-nodes it should never have different values for different Solr-nodes in the same cluster, and therefore the credentials ought to be specified on a global level (e.g. in ZK) instead of on a "per node" level as VM-params are

Guess this should not be a TODO here since we're inside the SysProp impl, but rather open a JIRA for a ZK auth cred impl once this gets in

h3. In SecurityDistributedTest:

{code}
// TODO It ought to have been 403 below instead of -1, but things are just crappy with respect to 403 handling around the code
doAndAssertSolrExeption(-1 /*403*/, new Callable<Object>() {
{code}

Do you remember why you put this comment instead of cleaning up the code?

{code}
/* TODO Seems like the single control-node is sending requests to itself in order to handle get!?
      controlClient.query(params, METHOD.GET, SEARCH_CREDENTIALS);*/
{code}

Dead code, better remove it, or is there something to clarify?

{code}
// TODO: REMOVE THIS SLEEP WHEN WE HAVE COLLECTION API RESPONSES
Thread.sleep(10000);
{code}

There is SOLR-4577 which seems to be fixed already, can we perhaps spin off another JIRA to add a return status from {{AbstractFullDistribZkTestBase#createCollection()}} and friends. That way we can avoid adding another 10s of sleep through this test

h3. In AuthCredentials

{code}
// TODO we ought to test if authMethods is already unmodifiable and not wrap it if it is, but I hope/guess
// Collections.unmodifiableSet will do that internally - I found no way to test if a Set is unmodifiable
this.authMethods = Collections.unmodifiableSet(authMethods);
{code}

Anyone who *knows* if this is safe? If so better remove the whole TODO


was (Author: janhoy):
There's a TODO in SystemPropertiesAuthCredentialsInternalRequestFactory
{blockquote}
TODO since internalAuthCredentials is something you use for "internal" requests against other Solr-nodes it should never
have different values for different Solr-nodes in the same cluster, and therefore the credentials ought to be specified
on a global level (e.g. in ZK) instead of on a "per node" level as VM-params are
{blockquote}

> 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org