[
https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14216585#comment-14216585
]
Gregory Chanan commented on SOLR-6625:
--------------------------------------
bq. Actually SOLR-4470 aims at introducing a framework for any
authentication-type, and then (for now) implement basic-auth using this
framework
Ah, I see, I misinterpreted the SOLR-4470 code in HttpSolrServer -- it uses
BasicAuthCache and BasicScheme which I thought were in reference to basic auth,
but they are really just default implementations.
What I'm really arguing -- and it's my fault I didn't make it clear with
example code -- is that the authentication type may affect how you want the
http requests to look, beyond just the credentials. For example, I'm using an
authentication filter based off of Hadoop's AuthenticationFilter
(https://github.com/apache/hadoop/blob/7250b0bf914a55d0fa4802834de7f1909f1b0d6b/hadoop-common-project/hadoop-auth/src/main/java/org/apache/hadoop/security/authentication/server/AuthenticationFilter.java).
That filter does SPNego negotiation on the first request, but sets a cookie
you can use to avoid the negotiation on subsequent requests. So, I wouldn't
want the the SOLR-4470 implementation where I buffer up every request; I only
want to do that on the first request to the server on the connection.
>From seeing the SOLR-4470 code, though, it looks like I was thinking about
>this incorrectly. Instead of the HttpClientCallback being a function of the
>HttpSolrServer, it's really a function of the AuthCredentials implementation.
>So, the default implementation would just be the
>credentialsButNonPreemptive/getHttpContextForRequest code you have in
>HttpSolrServer in SOLR-4470, but other AuthCredentials implementations could
>override. Does that sound right to you, [~steff1193]?
bq. I do not know if it is an improvement compared to your approach. I just
implemented in a way that worked. Supporting non-preemptive authenticating
POST-requests was not the main focus of SOLR-4470, so I just quickly did it in
the way that I found it could be done - without considering performance or
anything
Cool, I'll investigate in another jira.
> 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
>
>
> 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
