[
https://issues.apache.org/jira/browse/SOLR-8842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-8842:
-----------------------------
Attachment: SOLR-8842.patch
Full set of changes given in the description along with modified and added test
cases
> 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
> 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
