Christopher Kolstad 3acb116ab2 feat: Separate api token roles (#4019) ... ## What As part of the move to enable custom-root-roles, our permissions model was found to not be granular enough to allow service accounts to only be allowed to create read-only tokens (client, frontend), but not be allowed to create admin tokens to avoid opening up a path for privilege escalation. ## How This PR adds 12 new roles, a CRUD set for each of the three token types (admin, client, frontend). To access the `/api/admin/api-tokens` endpoints you will still need the existing permission (CREATE_API_TOKEN, DELETE_API_TOKEN, READ_API_TOKEN, UPDATE_API_TOKEN). Once this PR has been merged the token type you're modifying will also be checked, so if you're trying to create a CLIENT api-token, you will need `CREATE_API_TOKEN` and `CREATE_CLIENT_API_TOKEN` permissions. If the user performing the create call does not have these two permissions or the `ADMIN` permission, the creation will be rejected with a `403 - FORBIDDEN` status. ### Discussion points The test suite tests all operations using a token with operation_CLIENT_API_TOKEN permission and verifies that it fails trying to do any of the operations against FRONTEND and ADMIN tokens. During development the operation_FRONTEND_API_TOKEN and operation_ADMIN_API_TOKEN permission has also been tested in the same way. I wonder if it's worth it to re-add these tests in order to verify that the permission checker works for all operations, or if this is enough. Since we're running them using e2e tests, I've removed them for now, to avoid hogging too much processing time.		2023-06-20 14:21:14 +02:00
..
lib	feat: Separate api token roles (#4019)	2023-06-20 14:21:14 +02:00
mailtemplates
migrations	feat: Separate api token roles (#4019)	2023-06-20 14:21:14 +02:00
test	feat: Separate api token roles (#4019)	2023-06-20 14:21:14 +02:00
migrator.ts
server-dev.ts	feat: walking skeleton of the advanced playground (#3949)	2023-06-12 11:01:52 +02:00
server.ts