From dev-return-357629-archive-asf-public=cust-asf.ponee.io@lucene.apache.org Mon Jun 3 21:25:03 2019
Return-Path:
X-Original-To: archive-asf-public@cust-asf.ponee.io
Delivered-To: archive-asf-public@cust-asf.ponee.io
Received: from mail.apache.org (hermes.apache.org [207.244.88.153])
by mx-eu-01.ponee.io (Postfix) with SMTP id 84F5018062F
for ; Mon, 3 Jun 2019 23:25:03 +0200 (CEST)
Received: (qmail 56847 invoked by uid 500); 3 Jun 2019 21:25:01 -0000
Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
List-Help:
List-Unsubscribe:
List-Post:
List-Id:
Reply-To: dev@lucene.apache.org
Delivered-To: mailing list dev@lucene.apache.org
Received: (qmail 56827 invoked by uid 99); 3 Jun 2019 21:25:01 -0000
Received: from mailrelay1-us-west.apache.org (HELO mailrelay1-us-west.apache.org) (209.188.14.139)
by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 03 Jun 2019 21:25:01 +0000
Received: from jira-lw-us.apache.org (unknown [207.244.88.139])
by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id 98E02E0157
for ; Mon, 3 Jun 2019 21:25:00 +0000 (UTC)
Received: from jira-lw-us.apache.org (localhost [127.0.0.1])
by jira-lw-us.apache.org (ASF Mail Server at jira-lw-us.apache.org) with ESMTP id 3207720FEB
for ; Mon, 3 Jun 2019 21:25:00 +0000 (UTC)
Date: Mon, 3 Jun 2019 21:25:00 +0000 (UTC)
From: =?utf-8?Q?Jan_H=C3=B8ydahl_=28JIRA=29?=
To: dev@lucene.apache.org
Message-ID:
In-Reply-To:
References:
Subject: [jira] [Commented] (SOLR-13510) Intermittent 401's for internode
requests with basicauth enabled
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394
[ https://issues.apache.org/jira/browse/SOLR-13510?page=3Dcom.atlassian=
.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D1685=
5064#comment-16855064 ]=20
Jan H=C3=B8ydahl commented on SOLR-13510:
------------------------------------
[~gerlowskija] with your understanding of the situation, are you able to cr=
eate 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=C2=A0Http2SolrClie=
nt 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 req=
uest as this is done in slightly different way, and probably not tested. Th=
e logic in asserting that PKIAuthPlugin registers its interceptor for HTTP1=
and HTTP2 may also be fragile or slightly different.=C2=A0If setting {{-Ds=
olr.http1=3Dtrue}} 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)=20
> 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 querie=
s
> (through the admin UI currently) I non-deterministically get 401 response=
s
> 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$Remot=
eSolrException",
> "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. \n\n http-equiv=3D\"Content-Type\"
> content=3D\"text/html;charset=3Dutf-8\"/>\nError 401 require
> authentication\n\nHTTP ERROR 401
\nProble=
m
> accessing /solr/gettingstarted_shard4_replica_n6/select. Reason:\n
> require authentication
\n\n\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 putfi=
le
> /security.json
> {
> "authentication": {
> "blockUnknown": true,
> "class": "solr.BasicAuthPlugin",
> "credentials": {
> "solradmin": "PIWZwkGnEKxKnqUs3X08xmbmYBaYyAeP3FiKp7fmeHc=3D
> Lnbp6bEbE7Ap8lXvQDKkUX2Xw53QDgP6Ae8QRT0P5/A=3D"
> }
> },
> "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) l=
ook 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 r=
equests regardless of the recipient of the initial request, and even when a=
ll nodes have a shard replica).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org