[
https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ishan Chattopadhyaya updated SOLR-6625:
---------------------------------------
Attachment: SOLR-6625_interceptor.patch
Thanks for your review, [~gchanan] and [~anshumg].
bq. 1. How is configuration handled? Is it the responsibility of the
authentication layer to specify the HttpRequestInterceptor to use for all
requests?
My thought was that the authentication (SOLR-7274) and authorization
(SOLR-7275) plugins would add their own interceptors, e.g. to pass in original
request's user principal or ACL to a subrequest. The work of taking these
things, i.e. user principal, ACL or whatever else is generated from authc/authz
plugins, from original user request and adding it to
SolrRequest/SolrQueryRequest could be dealt in another issue.
bq. 2. There is some question about passing in SolrRequests (client) vs
SolrQueryRequests (server). Presumably the authentication layer needs to
operate on the client side (often the authentication requirements will be the
same), but what are you supposed to do with the SolrQueryRequest? You've sort
of hidden it by putting it in the context, but that seems fragile; we should
have our own Context that makes clear what is available, but if you pull in
SolrQueryRequest, then clients need access to server data structures, which
isn't ideal. Perhaps the right thing to do is split up client vs server
interceptors?
In this new patch, I've created two context objects, SolrHttpContext (client,
encapsulates SolrRequest) and SolrQueryRequestContext (server, encapsulates
SolrQueryRequest). Based on which of the contexts is received, an interceptor
can do its thing with these request objects.
bq. 3. Can the request interceptor do everything our own callback can do?
There are sample tests in the patch which add cookies, modify the URL, etc. It
would be good to see those tests with the new implementation
I've added similar tests to HttpSolrClient that were in the previous patches by
you and [~steff1193].
bq. 4. How do you check that we actually pass the correct information to the
interceptor? Per Steffensen described this above; what if someone adds another
httpclient.execute call tomorrow and doesn't pass the SolrRequest object? We'll
never know, so relying on the HttpRequestInterceptor didn't really help us (it
automatically dispatches but doesn't check that it has all the info it needs to
dispatch). It just limits us to an interface we don't control. We need some way
of enforcing the property that every call to httpclient has the information we
need.
That's a good point, thanks for bringing it up, since I had missed it. One of
the ways I could think of enforcing this was to add an interceptor that always
checks if an httpclient.execute() call puts in a SolrHttpContext object, and
throws an exception if not. Another way, we can forbid calls to
httpclient.execute() without a SolrHttpContext context. In this patch, I've
added done of these.
> 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,
> SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch,
> SOLR-6625_r1654079.patch, SOLR-6625_r1654079.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
