[jira] [Commented] (SOLR-8842) security should use an API to expose the permission name instead of using HTTP params
[
https://issues.apache.org/jira/browse/SOLR-8842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15248143#comment-15248143
]
ASF subversion and git services commented on SOLR-8842:
---
Commit 7be7e8beb965714dd1fb1b85f711e9c8a882d088 in lucene-solr's branch
refs/heads/branch_6x from [~hossman_luc...@fucit.org]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=7be7e8b ]
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
[jira] [Commented] (SOLR-8842) security should use an API to expose the permission name instead of using HTTP params
[
https://issues.apache.org/jira/browse/SOLR-8842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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
[jira] [Commented] (SOLR-8842) security should use an API to expose the permission name instead of using HTTP params
[
https://issues.apache.org/jira/browse/SOLR-8842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15201170#comment-15201170
]
ASF subversion and git services commented on SOLR-8842:
---
Commit faa0586b31d5644360646010ceaf530cbe227498 in lucene-solr's branch
refs/heads/apiv2 from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=faa0586 ]
SOLR-8842: security rules made more foolproof by asking the requesthandler
about the well known
permission name.
The APIs are also modified to ue 'index' as the unique
identifier instead of name.
Name is an optional attribute
now and only to be used when specifying
well-known permissions
> 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
[jira] [Commented] (SOLR-8842) security should use an API to expose the permission name instead of using HTTP params
[
https://issues.apache.org/jira/browse/SOLR-8842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15200066#comment-15200066
]
ASF subversion and git services commented on SOLR-8842:
---
Commit faa0586b31d5644360646010ceaf530cbe227498 in lucene-solr's branch
refs/heads/master from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=faa0586 ]
SOLR-8842: security rules made more foolproof by asking the requesthandler
about the well known
permission name.
The APIs are also modified to ue 'index' as the unique
identifier instead of name.
Name is an optional attribute
now and only to be used when specifying
well-known permissions
> 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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8842) security should use an API to expose the permission name instead of using HTTP params
[
https://issues.apache.org/jira/browse/SOLR-8842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15200069#comment-15200069
]
ASF subversion and git services commented on SOLR-8842:
---
Commit 54e827e9b69aa85c967a69252e87a4157633a754 in lucene-solr's branch
refs/heads/branch_6x from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=54e827e ]
SOLR-8842: security rules made more foolproof by asking the requesthandler
about the well known
permission name.
The APIs are also modified to ue 'index' as the unique
identifier instead of name.
Name is an optional attribute
now and only to be used when specifying
well-known permissions
> 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: 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
