lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noble Paul (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (SOLR-8842) security should use an API to expose the permission name instead of using HTTP params
Date Thu, 17 Mar 2016 18:05:33 GMT

     [ https://issues.apache.org/jira/browse/SOLR-8842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Noble Paul updated SOLR-8842:
-----------------------------
    Labels: security  (was: )

> 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
>         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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message