Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature] Support more explicit permissions on ServiceAPI #334

Open
fmigneault opened this issue May 15, 2020 · 1 comment
Open

[Feature] Support more explicit permissions on ServiceAPI #334

fmigneault opened this issue May 15, 2020 · 1 comment
Assignees
Labels
enhancement Improvements in term of performance or behaviour feature New feature to be developed
Milestone

Comments

@fmigneault
Copy link
Collaborator

Service of type ServiceAPI allows read/write/read-match/write-match permissions.

It should be extended to allow explicit permissions as standard request methods, ie: GET, POST, DELETE, PUT, etc. since this is what it already filters, but combining multiple method types under read/write categories

For backward compatibility reasons, the original 4 permissions should remain.
The service would then need to validate for example that GET request is granted access if either combination between explicit GET or read-category (on any parent route) or GET-match/read-match (on exact route) is given.
An admin who desires to restrict more granular permissions would have more flexibility to do so with whichever variant better fits his need.

@fmigneault fmigneault added the feature New feature to be developed label May 15, 2020
@fmigneault fmigneault self-assigned this May 15, 2020
@fmigneault fmigneault added the enhancement Improvements in term of performance or behaviour label May 15, 2020
@fmigneault
Copy link
Collaborator Author

relates to #342

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Improvements in term of performance or behaviour feature New feature to be developed
Projects
None yet
Development

No branches or pull requests

1 participant