Thanks for letting us know… Erick
> On Jun 12, 2019, at 10:42 AM, Brian Lininger <brian.linin...@veeva.com> wrote: > > Turns out that the problem wasn't intermittent, but that our streaming code > isn't properly setting the credentials on the client. Not sure why that is > yet, but it's not an issue with Solr, it just looked intermittent because > of the intermittent use of streaming in our application... > > > On Wed, Jun 12, 2019 at 1:55 AM Colvin Cowie <colvin.cowie....@gmail.com> > wrote: > >> Hi Brian, >> >> That's correct, we never had any issues with authentication on Solr 6.x, as >> far as I remember. >> Have you checked Solr's own logs to see whether the 401s are coming from >> internode requests between shards, or if they are coming from the initial >> request to Solr from the client? >> I believe forwardCredentials was only added in Solr 8.0, and would only >> affect internode requests anyway ( >> https://issues.apache.org/jira/browse/SOLR-12799) >> >> How are you doing the authentication on the client? Our client code was >> originally written when we were on Solr 5.2.1, but we do our authentication >> using an org.apache.http.HttpRequestInterceptor and >> org.apache.http.client.CredentialsProvider on the HttpClient we pass to the >> CloudSolrClient... there's something similar described on SO >> >> https://stackoverflow.com/questions/2014700/preemptive-basic-authentication-with-apache-httpclient-4 >> >> HTH >> >> On Tue, 11 Jun 2019 at 23:43, Brian Lininger <brian.linin...@veeva.com> >> wrote: >> >>> Thanks Erick, >>> I had read thru https://issues.apache.org/jira/browse/SOLR-13510 earlier >>> today but it seemed specific to Solr 8 as Colvin Cowie wasn't able to >>> reproduce on 7.7.0 or 7.7.1. I am going to see if the >> 'forwardCredentials' >>> workaround resolves this for 6.6.6, fingers crossed.... >>> Brian >>> >>> On Tue, Jun 11, 2019 at 3:33 PM Erick Erickson <erickerick...@gmail.com> >>> wrote: >>> >>>> Looks like: https://issues.apache.org/jira/browse/SOLR-13510 >>>> >>>>> On Jun 11, 2019, at 3:08 PM, Brian Lininger < >> brian.linin...@veeva.com> >>>> wrote: >>>>> >>>>> Hello Solr Experts, >>>>> I've hit an issue with Solr and BasicAuth that is stumping me at the >>>>> moment. We've configured a basic security.json to require BasicAuth >>>>> credentials for read/update to all collections in Solr, but we allow >>>>> un-authenticated requests to Solr admin endpoint (don't ask why). It >>>> looks >>>>> like (but with actual encoded password & salt): >>>>> { >>>>> "authentication":{ >>>>> "class":"solr.BasicAuthPlugin", >>>>> "blockUnknown": false, >>>>> "credentials":{ >>>>> "my_search_user":"searchPasswordEncoded searchPasswordSalt" >>>>> } >>>>> }, >>>>> "authorization":{ >>>>> "class":"solr.RuleBasedAuthorizationPlugin", >>>>> "permissions":[ >>>>> {"name":"read", "role":"search_user"}, >>>>> {"name":"update", "role":"search_user"} >>>>> ], >>>>> "user-role":{ >>>>> "my_search_user":"search_user" >>>>> } >>>>> }} >>>>> >>>>> This works as expected *except* that we're getting intermittent 401 >>>>> responses intermingled with successful searches: >>>>> >>>>> 192.168.0.10 - - [11/Jun/2019:00:18:11 +0000] "POST >>>>> /solr/instance_42300/select HTTP/1.1" *200* 594 1 >>>>> 192.168.0.10 - - [11/Jun/2019:00:18:11 +0000] "POST >>>>> /solr/instance_42300/select HTTP/1.1" *200* 594 1 >>>>> 192.168.0.10 - - [11/Jun/2019:00:18:11 +0000] "POST >>>>> /solr/instance_42300/select HTTP/1.1" *401* 441 0 >>>>> 192.168.0.10 - - [11/Jun/2019:00:18:15 +0000] "POST >>>>> /solr/instance_42300/select HTTP/1.1" *401* 441 0 >>>>> 192.168.0.10 - - [11/Jun/2019:00:18:15 +0000] "POST >>>>> /solr/instance_42300/select HTTP/1.1" *401* 441 0 >>>>> 192.168.0.10 - - [11/Jun/2019:00:18:16 +0000] "POST >>>>> /solr/instance_42300/select HTTP/1.1" *401* 441 0 >>>>> 192.168.0.10 - - [11/Jun/2019:00:18:21 +0000] "POST >>>>> /solr/instance_42300/select HTTP/1.1" *401* 441 1 >>>>> 192.168.0.10 - - [11/Jun/2019:00:18:25 +0000] "POST >>>>> /solr/instance_42300/select HTTP/1.1" *401* 441 1 >>>>> 192.168.0.10 - - [11/Jun/2019:00:18:25 +0000] "POST >>>>> /solr/instance_42300/select HTTP/1.1" *200* 594 2 >>>>> 192.168.0.10 - - [11/Jun/2019:00:18:27 +0000] "POST >>>>> /solr/instance_42300/select HTTP/1.1" *401* 441 1 >>>>> 192.168.0.10 - - [11/Jun/2019:00:18:27 +0000] "POST >>>>> /solr/instance_42300/select HTTP/1.1" *401* 441 0 >>>>> 192.168.0.10 - - [11/Jun/2019:00:18:28 +0000] "POST >>>>> /solr/instance_42300/select HTTP/1.1" *401* 441 1 >>>>> 192.168.0.10 - - [11/Jun/2019:00:18:29 +0000] "POST >>>>> /solr/instance_42300/select HTTP/1.1" *200* 594 2 >>>>> 192.168.0.10 - - [11/Jun/2019:00:18:29 +0000] "POST >>>>> /solr/instance_42300/select HTTP/1.1" *401* 441 1 >>>>> 192.168.0.10 - - [11/Jun/2019:00:18:30 +0000] "POST >>>>> /solr/instance_42300/select HTTP/1.1" *401* 441 1 >>>>> 192.168.0.10 - - [11/Jun/2019:00:18:34 +0000] "POST >>>>> /solr/instance_42300/select HTTP/1.1" *401* 441 1 >>>>> 192.168.0.10 - - [11/Jun/2019:00:18:37 +0000] "POST >>>>> /solr/instance_42300/select HTTP/1.1" *401* 441 0 >>>>> >>>>> As you can see form the logs, we're getting 401 errors mixed with 200 >>>>> success responses. We're using a shared instance of CloudSolrClient >>> and >>>>> these requests are coming from the same AppServer JVM, and as you can >>> see >>>>> from the above log snippet we get success and failures interleaved. >>>> We're >>>>> using Solr 6.6.6, collections are a single shard with 2 replicas. We >>> are >>>>> seeing this behavior across multiple environments, each one has 2-5 >>> Solr >>>>> instances. Anyone see this type of behavior before? Any insight or >>>>> thoughts on what we're doing wrong or is this a bug in Solr that I >>>> stumbled >>>>> upon.... >>>>> >>>>> Thanks in advance for the help! >>>>> Brian >>>> >>>> >>> >>> -- >>> >>> >>> *Brian Lininger* >>> Technical Architect, Infrastructure & Search >>> *Veeva Systems * >>> brian.linin...@veeva.com >>> www.veeva.com >>> >>> *This email and the information it contains are intended for the intended >>> recipient only, are confidential and may be privileged information exempt >>> from disclosure by law.* >>> *If you have received this email in error, please notify us immediately >> by >>> reply email and delete this message from your computer.* >>> *Please do not retain, copy or distribute this email.* >>> >>
