[ https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14241254#comment-14241254 ]
Per Steffensen commented on SOLR-6625: -------------------------------------- bq. Maybe Per Steffensen can chime in with the motivation there rather than always using the static credentials – I'm guessing it is because there is some organization-specific authorization checking expecting the actual user who made the original request. * Every paranoid customers. In general we/they just do not want a user to be able to indirectly (through distributed sub-requests) get a response to a query he is not allowed to fire directly. There is a lot of details to it that I will spare you, but overall we are also 1) using authorization to prevent specific groups of users to do queries (directly or indirectly) that takes certain amounts of resources from the system or 2) to fetch certain fields or any information that can be derived from those fields. Ad 1) By a lot of testing we know which types of queries really takes a lot of resources out of our system, but it is hard to be sure that a query that does not seem to be such a query, does not indirectly fire such queries in distributed sub-requests. Ad 2) Just because an outer request does not specifically ask for a certain field, it is hard to know that the indirect sub-request also does not, even though in practice it is so (except for id an score) * Distributed audit logging * Etc. I realize that the reasons we want the credentials from the outer request forwarded in sub-requests are very thin. I understand if this is not something that you feel is necessary to support in Apache Solr. But if it does not make the solution much more complicated you might just support it. I do not think SOLR-4470 is a complicated solution - most of it, really, is testing. bq. Likewise you can see all of the various other authentication schemes HttpClient supports (SPNego included) SOLR-4470 does not try to do itself what HttpClient can already do. The HttpClient capabilities can just be used outside or through the authentication-framework introduced in SOLR-4470. SOLR-4470 is mostly about joggling the credentials inside Solr-nodes. When they have to be added to requests, of course use HttpClient capabilities. bq. To get around this, we use secure impersonation Interesting! > HttpClient callback in HttpSolrServer > ------------------------------------- > > Key: SOLR-6625 > URL: https://issues.apache.org/jira/browse/SOLR-6625 > Project: Solr > Issue Type: Improvement > Components: SolrJ > Reporter: Gregory Chanan > Assignee: Gregory Chanan > Priority: Minor > Attachments: SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, > SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch > > > Some of our setups use Solr in a SPNego/kerberos setup (we've done this by > adding our own filters to the web.xml). We have an issue in that SPNego > requires a negotiation step, but some HttpSolrServer requests are not > repeatable, notably the PUT/POST requests. So, what happens is, > HttpSolrServer sends the requests, the server responds with a negotiation > request, and the request fails because the request is not repeatable. We've > modified our code to send a repeatable request beforehand in these cases. > It would be nicer if HttpSolrServer provided a pre/post callback when it was > making an httpclient request. This would allow administrators to make > changes to the request for authentication purposes, and would allow users to > make per-request changes to the httpclient calls (i.e. modify httpclient > requestconfig to modify the timeout on a per-request basis). -- This message was sent by Atlassian JIRA (v6.3.4#6332) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org