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

Reply via email to