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

Jan Høydahl commented on SOLR-13510:
------------------------------------

[~gerlowskija] with your understanding of the situation, are you able to create 
a patch with a failing unit test? I tried creating 3 extra collections in 
BasicAuthIntegrationTest (which has 3 nodes) but it did not trigger any 
failures.

I wonder if there may be some interaction with HTTP2 and Http2SolrClient here? 
If the outside client uses HTTP1 and inter-node traffic is always HTTP2, then 
it could be that we fail to convey the credentials from the request as this is 
done in slightly different way, and probably not tested. The logic in asserting 
that PKIAuthPlugin registers its interceptor for HTTP1 and HTTP2 may also be 
fragile or slightly different. If setting {{-Dsolr.http1=true}} when starting 
Solr fixes the issue, then this theory is proven.

> Intermittent 401's for internode requests with basicauth enabled
> ----------------------------------------------------------------
>
>                 Key: SOLR-13510
>                 URL: https://issues.apache.org/jira/browse/SOLR-13510
>             Project: Solr
>          Issue Type: Bug
>      Security Level: Public(Default Security Level. Issues are Public) 
>          Components: Authentication
>    Affects Versions: master (9.0)
>            Reporter: Jason Gerlowski
>            Priority: Major
>
> We recently got a bug report on the mailing list:
> {quote}
> On Solr 8.1.1, using our previously working security.json, running queries
> (through the admin UI currently) I non-deterministically get 401 responses
> on queries when a collection has more than 1 shard. Increasing the number
> of shards in the collection makes the errors more likely.
> {
>   "responseHeader":{
>     "zkConnected":true,
>     "status":401,
>     "QTime":30,
>     "params":{
>       "q":"*:*",
>       "_":"1559474550365"}},
>   "error":{
>     "metadata":[
> "error-class","org.apache.solr.client.solrj.impl.BaseHttpSolrClient$RemoteSolrException",
> "root-error-class","org.apache.solr.client.solrj.impl.BaseHttpSolrClient$RemoteSolrException"],
>     "msg":"Error from server at null: Expected mime type
> application/octet-stream but got text/html. <html>\n<head>\n<meta
> http-equiv=\"Content-Type\"
> content=\"text/html;charset=utf-8\"/>\n<title>Error 401 require
> authentication</title>\n</head>\n<body><h2>HTTP ERROR 401</h2>\n<p>Problem
> accessing /solr/gettingstarted_shard4_replica_n6/select. Reason:\n<pre>
>  require authentication</pre></p>\n</body>\n</html>\n",
>     "code":401}}
> {quote}
> The reporter (credit to Colvin Cowie) also gives reproduction steps:
> {quote}
>    # Extract solr 8.1.1.
>    # bin\solr start -e cloud
>         1 node / [default port] / [default collection name] / 4 shards / 1
> replica / [_default configuration]
>    # server\scripts\cloud-scripts\zkcli -zkhost localhost:9983 -cmd putfile
> /security.json <path-to-security-json-file-with-content-below>
> {
>     "authentication": {
>         "blockUnknown": true,
>         "class": "solr.BasicAuthPlugin",
>         "credentials": {
>             "solradmin": "PIWZwkGnEKxKnqUs3X08xmbmYBaYyAeP3FiKp7fmeHc=
> Lnbp6bEbE7Ap8lXvQDKkUX2Xw53QDgP6Ae8QRT0P5/A="
>         }
>     },
>     "authorization": {
>         "class": "solr.RuleBasedAuthorizationPlugin",
>         "permissions": [{ "name": "all", "role": "admin"} ],
>         "user-role": {"solradmin": "admin"}
>     }
> }
> {quote}
> (Minor edits for conciseness)
> I'm able to reproduce this bug as well.  Other auth issues (SOLR-13472) look 
> like they're impacted by the topography of the collection and cluster.  But 
> this doesn't seem affected by that at all (401's occur on inter-node requests 
> regardless of the recipient of the initial request, and even when all nodes 
> have a shard replica).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to