Hi, thanks I'll give that a go when I get a chance. I was trying to reply to an older thread ( http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201904.mbox/%3CCAF2DzVXeVZqnixnkbzw0La1ui5N5-RG9PwfMBHG9vmkfBSMzJA%40mail.gmail.com%3E), which I don't have in my mailbox, so obviously didn't reply to the right address to get my response threaded so mine has appeared on its own. Oops.
A JIRA issue was raised on that thread https://issues.apache.org/jira/browse/SOLR-13421 but it's not had any attention. On Mon, 3 Jun 2019 at 14:46, Jason Gerlowski <gerlowsk...@gmail.com> wrote: > Hi Colvin, > > We're still taking a look at fixing the bug, but as a workaround in > the meantime, you can look into adding a "forwardCredentials":true > property under the "authentication" section of security.json. That > seems to fix the issue in my reproduction at least. > > e.g. > > { > "authentication": { > "blockUnknown": true, > "class": "solr.BasicAuthPlugin", > "credentials": { > "solradmin": "<encoded-pw>" > }, > "forwardCredentials": true > }, > ... > } > > Jason > > On Mon, Jun 3, 2019 at 9:31 AM Jason Gerlowski <gerlowsk...@gmail.com> > wrote: > > > > One last note: as far as I can tell, nothing about this issue is > > specific to JSON Faceting or the JSON request API. It can be > > triggered just as easily with "/select?q=*:*". > > > > The bug created for this is: SOLR-13510 > > > > On Mon, Jun 3, 2019 at 9:17 AM Jason Gerlowski <gerlowsk...@gmail.com> > wrote: > > > > > > I'm also able to reproduce this bug on master. A few more notes about > > > the bad behavior: > > > > > > - the behavior occurs regardless of the specific permissions > > > configured in security.json. (i.e. whether the top permission is > > > "all", or "security-edit", or there are no permissions at all.) > > > - I tried looking for a pattern in which requests saw the 401s, but > > > didn't have any luck. The 401 occurs when talking to the whole > > > collection or targeting individual cores directly. It occurs when > > > curl hits a host containing a replica for the collection in question, > > > and when it doesnt. etc. This distinguishes it from SOLR-13472, which > > > seems more specific to collection structure/layout. > > > > > > I'll create a bug for this in JIRA. > > > > > > On Sun, Jun 2, 2019 at 9:53 AM Colvin Cowie < > colvin.cowie....@gmail.com> wrote: > > > > > > > > Hello. I encountered this issue too and wrote this up before I found > this > > > > thread, but I thought I might as well post it still, if it helps... > > > > > > > > Currently I'm trying to move our product on to Solr 8.1.1. We are > currently > > > > using 6.6.6, so things have definitely moved on. > > > > > > > > We use the BasicAuthPlugin + RuleBasedAuthorizationPlugin to lock > down Solr > > > > (and we also secure our zookeeper). Here's an example for solradmin > as the > > > > user and password > > > > > > > > { > > > > "authentication": { > > > > "blockUnknown": true, > > > > "class": "solr.BasicAuthPlugin", > > > > "credentials": { > > > > "solradmin": > "PIWZwkGnEKxKnqUs3X08xmbmYBaYyAeP3FiKp7fmeHc= > > > > Lnbp6bEbE7Ap8lXvQDKkUX2Xw53QDgP6Ae8QRT0P5/A=" > > > > } > > > > }, > > > > "authorization": { > > > > "class": "solr.RuleBasedAuthorizationPlugin", > > > > "permissions": [ > > > > { > > > > "name": "all", > > > > "role": "admin" > > > > } > > > > ], > > > > "user-role": { > > > > "solradmin": "admin" > > > > } > > > > } > > > > } > > > > > > > > > > > > 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}} > > > > > > > > The security stats indicate this is happening because the requests > do not > > > > have credentials with them, e.g. > > > > > http://localhost:8983/solr/#/gettingstarted_shard4_replica_n6/plugins?type=security&entry=org.apache.solr.security.BasicAuthPlugin > > > > > > > > org.apache.solr.security.BasicAuthPlugin > > > > class: > > > > org.apache.solr.security.BasicAuthPlugin > > > > description: > > > > Authentication Plugin > org.apache.solr.security.BasicAuthPlugin > > > > stats > > > > SECURITY./authentication.authenticated: > > > > 182 > > > > SECURITY./authentication.errors.count: > > > > 0 > > > > SECURITY./authentication.failMissingCredentials: > > > > 58 > > > > SECURITY./authentication.failWrongCredentials: > > > > 0 > > > > SECURITY./authentication.passThrough: > > > > 0 > > > > SECURITY./authentication.requestTimes.meanRate: > > > > 0.4183414110946125 > > > > SECURITY./authentication.requests: > > > > 240 > > > > SECURITY./authentication.totalTime: > > > > 117791100 > > > > > > > > I assume that this is connected to the changes around > > > > https://issues.apache.org/jira/browse/SOLR-7896 and > > > > https://issues.apache.org/jira/browse/SOLR-13344 I've tested with > Solr > > > > 7.6.0 and it appears to be unaffected > > > > > > > > Repro steps: > > > > # 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 <example-security.json file with content from example > above> > > > > > > > > # Execute repeated GETS to > > > > http://localhost:8983/solr/gettingstarted/select?q=*%3A* - a lot of > them, > > > > but not all, will fail with 401s > > > > > > > > > > > > Also as a side note, because the authentication is now done through > the > > > > form login rather than the browser basic auth, if you go directly to > a non > > > > UI url (e.g. http://localhost:8983/solr/main_index/select?q=*%3A*) > you have > > > > to authenticate to it using the browser's basic auth prompt. Which is > > > > slightly annoying since the query page in the Admin UI generates > links to > > > > it for the queries you run, and you've already authenticated to get > there. > > > > But it's not a massive burden or anything... I guess I just preferred > > > > having the browser BA prompt. > > > > > > > > Thanks >
