[
https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14217591#comment-14217591
]
Per Steffensen commented on SOLR-6625:
--------------------------------------
Sorry I do not have the time to go into details. But from quick reading, and as
I remember the SOLR-4470 implementation, most/all of what you say sounds
reasonable.
Please note that SOLR-4470 hasnt been committed to the Apache Solr code-base. I
provided it long time ago, and just recently [~janhoy] and I updated it to fit
tip of trunk, and I know Jan intended to try to push it to the code-base. Do
not know what happened after that.
Please also note that in SOLR-4470 I tried to prepare for additional
authentication types, but it is hard to make it 100% right when you do not know
the nature of the actual types being implemented in the future. Essence is that
{{AuthCredentials}} should carry [information about] the authentications to be
"used" for the request(s). How to "use" them is an implementation-detail of the
specific authentication type (implementing {{AbstractAuthMethod}}), and it may
require a little rearranging of code to implement authentication type #2.
Basing it on a general callback feature sound like good idea. I believe in
"never design for the future", but if I didnt at least try to sketch the idea
in a "framework", there is a big risk than the next authentication type would
be implemented in a completely different way. I also believe in "separation of
concerns", so I would really like the "authentication concern" to be handled in
one single place - {{AuthCredentials}} was my attempt to make such "a place".
> 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
