[
https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13933301#comment-13933301
]
Per Steffensen commented on SOLR-4470:
--------------------------------------
Sorry for being so slow getting back to you, but I am very very busy right now.
{quote}
{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?
{quote}
It ought to be 403 because 403 is the code we use for unauthroized. The reason
it is not propagated all the way through to the client (and we therefore cannot
assert it), is that LBHttpSolrServer retries on 403 (RETRY_CODES.add(403)).
When doing retries the internal exceptions are not propagated correctly. Why
LBHttpSolrServer wants to do retry on 403 is beyond me, but there is probably a
good reason. If there is a good reason then the fix should be make sure
internal exceptions are propagated correctly even on retries. If there is not
good reason I guess "RETRY_CODES.add(403)" could be removed from
LBHttpSolrServer - if you do that you can change the from -1's to 403's in
SecurityDistributedTest and it will be green. I did not dare to go struggle
with propagating exceptions correctly under this issue/ticket, so I just accept
for now that we cannot make a really good assert on error-code in
SecurityDistributedTest in this case.
{quote}
{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?
{quote}
One of the general ideas throughout SecurityDistributedTest is to show that
errors occur when wrong credentials are used in inter-Solr-node-requests. In
each case I demonstrate that even though there will be sent wrong credentials
in inter-Solr-node-requests we can still carry out the operation on
controlClient, because it is not part of a distributed setup (it will never
send inter-Solr-node-requests). This pattern is used throughout the test, but
it did not work for real-time gets, because controlClient got unauth exceptions
- concluded that this was because a Solr-node would always handle real-time
gets by forwarding the request to the node supposed to hold the document - ALSO
if this node is the node receiving the request and doing the forwarding.
I have just tried it and it seems this is not a problem anymore so the
code-lines can actually be activated - do the following change in both cases.
Change from
{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}
to
{code}
controlClient.query(getParams, METHOD.GET, SEARCH_CREDENTIALS);
{code}
But this might not work on 4.x branch when backporting. I do not know when this
forwarding-real-time-gets-to-yourself issue was fixed and whether it is on
branch_4x.
> 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: [email protected]
For additional commands, e-mail: [email protected]
