[jira] [Comment Edited] (SOLR-6625) HttpClient callback in HttpSolrServer

["Ishan Chattopadhyaya (JIRA)" <ji...@apache.org>]

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

Ishan Chattopadhyaya edited comment on SOLR-6625 at 4/21/15 4:51 PM:
---------------------------------------------------------------------

Thanks for your review, [~gchanan] and [~anshumg]. I've added another patch, for your review.

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.


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