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.* > > >
