[
https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14216313#comment-14216313
]
Per Steffensen commented on SOLR-6625:
--------------------------------------
bq. One thing I wanted to avoid with this patch is putting authentication-type
specific details in HttpSolrServer. SOLR-4470 has a little logic there that is
basic-auth specific
Actually SOLR-4470 aims at introducing a framework for any authentication-type,
and then (for now) implement basic-auth using this framework. It is prepared
for adding new authentication types. See {{AuthCredentials}} carrying any kind
of {{AbstractAuthMethod}} - currently only
{{AbstractAuthMethod}}-implementation is {{BasicHttpAuth}}. Adding a new
authentication type should basically be about adding a new
{{AbstractAuthMethod}}-implementation. But sorry, I do not remember to many
details. But what I do know, is that we have been using SOLR-4470 solution now
in production for a long time, without any problems at all.
bq. As for the suggestion of using a BufferedHttpEntity rather than the OPTIONS
approach I describe above, that certainly may be an improvement.
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
> 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
