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

Change how permissions work #189

Open
rolznz opened this issue Dec 13, 2023 · 0 comments
Open

Change how permissions work #189

rolznz opened this issue Dec 13, 2023 · 0 comments
Assignees

Comments

@rolznz
Copy link
Contributor

rolznz commented Dec 13, 2023

In #178 when introducing pay_keysend we changed from 1 permission -> 1 method to 1 permission -> multiple methods for payments.

So it no longer really makes sense to tie permissions to individual methods, but more like scopes: "invoices:read", "invoices:create", "payments:send" etc. (Also on the user side: it makes no sense for most users to differentiate between keysend and normal payments)

There is now a naming issue, because keysend payments depend on the pay_invoice permission rather than the keysend one (which does not exist)

What needs to change

  • AppPermission.RequestMethod (it's no longer for one request method). Maybe it can be called Scope and more like our OAuth API. e.g. payments:send
  • Migrate the current values of AppPermission.RequestMethod to be the new scopes e.g. invoices:create, invoices:read, payments:send etc.
  • Consider if it makes more sense to have a single permissions object per app (or permissions directly on the app table instead) and how to do this in a performant and flexible way - this would remove duplication on the AppPermission table (amount, created, expiry, etc. which are the same for all selected permissions). What is the best way to store the permissions?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants