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