Fixed in 6.6.6 and 7.7, please upgrade https://lucene.apache.org/solr/news.html <https://lucene.apache.org/solr/news.html> https://issues.apache.org/jira/browse/SOLR-12514 <https://issues.apache.org/jira/browse/SOLR-12514>
-- Jan Høydahl, search solution architect Cominvent AS - www.cominvent.com > 2. mai 2019 kl. 14:03 skrev adfel70 <adfe...@gmail.com>: > > Atuhorization bug (?) when making HTTP requests > > We are experiencing a problem when making HTTP requests to a cluster with > authorization plugin enabled. > Permissions are configured in security.json the following: > > { > ... authentication_settings ... > "authorization":{ > "class":"solr.RuleBasedAuthorizationPlugin", > "permissions":[ > { > "name": "read", > "role": "*" > }, > { > "name": "update", > "role": ["indexer", "admin"] > }, > { > "name": "all", > "role": "admin" > } > ], > "user-role": { > "admin_user": "admin", > "indexer_app": "indexer" > } > } > > Our goal is to give all users read-only access to the data, read+write > permissions to indexer_app user and full permissions to admin_user. > > While testing the ACLs with different users we encountered unclear results, > where in some cases a privileged user got HTTP 403 response (unauthorized > request): > - in some calls authenticated reader could query the data. > - in some calls 'indexer_app' user could query data nor update the data. > - 'admin_user' worked as expected. > In addition, the problems were only relevant to HTTP requests - SolrJ > requests were perfect... > > After further investigation we realized what seems to be the problem: HTTP > requests works correctly only when the collection has a core on the server > that got the initial request. For example: > Say we have a cloud made of 2 servers - 'host1' and 'host2' and collection > 'test' with one shard - core on host1: > > curl -u *reader_user*:XXXX "http://host1:8983/solr/test/select?q=*:*" > > --> code 200 as expected > curl -u *reader_user*:XXXX "http://host2:8983/solr/test/select?q=*:*" > > --> code 403 (error - should return result) > > curl -u *indexer_app*:XXXX "http://host1:8983/solr/test/select?q=*:*" > > --> code 200 as expected > curl -u *indexer_app*:XXXX "http://host1:8983/solr/test/update?commit=true" > --> code 200 as expected > curl -u *indexer_app*:XXXX "http://host2:8983/solr/test/select?q=*:*" > > --> code 403 (error - should return result) > curl -u *indexer_app*:XXXX "http://host2:8983/solr/test/update?commit=true" > --> code 403 (error - should return result) > > We guess 'admin_user' does not encounter any error due to the special > /'all'/ permission. > Tested both using basic and Kerberos authentication plugins and got the same > behaviour. > Is this should be opened as a bug? > Thanks. > > > > -- > Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html