[
https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14239541#comment-14239541
]
Steve Davids commented on SOLR-6625:
------------------------------------
bq. See SOLR-4470. That makes use of SolrRequest.getPreemptiveAuthentication,
so you'd need the actual SolrRequest
I took a look at the patch but not quite sure any of that is actually
necessary. Looking at the "what" detailed in SOLR-4470 they need to be able to
lock down Solr Cloud via BasicAuth, you can easily do this via HttpClient's
[BasicScheme|
http://hc.apache.org/httpcomponents-client-ga/httpclient/apidocs/org/apache/http/impl/auth/BasicScheme.html]
authentication scheme. Likewise you can see all of the various other
[authentication schemes|
http://hc.apache.org/httpcomponents-client-ga/httpclient/apidocs/org/apache/http/auth/AuthScheme.html]
HttpClient supports (SPNego included). This would seem to do the trick, except
for perhaps propagating the authentication from the original request though
this shouldn't really be a requirement since the challenge will be static in
the web container that you can live with having static credentials in the solr
distrib - if it changes deploy new config changes.
For further information on authentication via HttpClient check out their help
page here:
http://hc.apache.org/httpcomponents-client-ga/tutorial/html/authentication.html
bq. See the discussion above about SolrDispatchFilter. In that case, the client
needs to get the context of the SolrQueryRequest... For my case, in the
SolrDispatchFilter, I need to get some information from the SolrQueryRequest or
HttpServletRequest (basically, the authenticated user that's available in the
HttpServletRequest.getAttribute or SolrQueryRequest.getContext() or
SolrQueryRequest.getParams())
Are you using these credentials to execute distributed requests? Or would it
make sense to have a certain user hit the frontend shard, then that shard will
perform the distributed request on behalf of the system's authentication
credentials?
> 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
>
>
> 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
