[ https://issues.apache.org/jira/browse/SOLR-8842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15248147#comment-15248147 ]
ASF subversion and git services commented on SOLR-8842: ------------------------------------------------------- Commit 423ec098504836ccd9b6e742a5b93c7b40cb0aa3 in lucene-solr's branch refs/heads/master from [~hossman_luc...@fucit.org] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=423ec09 ] CHANGES.txt corrections - new features go in the New Features section (SOLR-8782, SOLR-8765, SOLR-8842) > security should use an API to expose the permission name instead of using > HTTP params > ------------------------------------------------------------------------------------- > > Key: SOLR-8842 > URL: https://issues.apache.org/jira/browse/SOLR-8842 > Project: Solr > Issue Type: Improvement > Reporter: Noble Paul > Assignee: Noble Paul > Labels: security > Fix For: master, 6.1 > > Attachments: SOLR-8842.patch, SOLR-8842.patch > > > Currently the well-known permissions are using the HTTP atributes, such as > method, uri, params etc to identify the corresponding permission name such as > 'read', 'update' etc. Expose this value through an API so that it can be more > accurate and handle various versions of the API > RequestHandlers will be able to implement an interface to provide the name > {code} > interface PermissionNameProvider { > Name getPermissionName(SolrQueryRequest req) > } > {code} > This means many significant changes to the API > 1) {{name}} does not mean a set of http attributes. Name is decided by the > requesthandler . Which means it's possible to use the same name across > different permissions. > examples > {code} > { > "permissions": [ > {//this permission applies to all collections > "name": "read", > "role": "dev" > }, > { > > // this applies to only collection x. But both means you are hitting a > read type API > "name": "read", > "collection": "x", > "role": "x_dev" > } > ] > } > {code} > 2) so far we have been using the name as something unique. We use the name to > do an {{update-permission}} , {{delete-permission}} or even when you wish to > insert a permission before another permission we used to use the name. Going > forward it is not possible. Every permission will get an implicit index. > example > {code} > { > "permissions": [ > { > "name": "read", > "role": "dev", > //this attribute is automatically assigned by the system > "index" : 1 > }, > { > "name": "read", > "collection": "x", > "role": "x_dev", > "index" : 2 > } > ] > } > {code} > 3) example update commands > {code} > { > "set-permission" : { > "index": 2, > "name": "read", > "collection" : "x", > "role" :["xdev","admin"] > }, > //this deletes the permission at index 2 > "delete-permission" : 2, > //this will insert the command before the first item > "set-permission": { > "name":"config-edit", > "role":"admin", > "before":1 > } > } > {code} > 4) you could construct a permission purely with http attributes and you > don't need any name for that. As expected, this will be appended atthe end of > the list of permissions > {code} > { > "set-permission": { > "collection": null, > "path":"/admin/collections", > "params":{"action":[LIST, CREATE]}, > "role": "admin"} > } > {code} > Users with existing configuration will not observe any change in behavior. > But the commands issued to manipulate the permissions will be different . -- This message was sent by Atlassian JIRA (v6.3.4#6332) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org