30ff9b38a4
If a personal access token is provided, after performing authorization for the account, perform an additional authorization specific to the personal access token. Once the UI is added, this will allow a user to create multiple personal access tokens, each with a specific access policy, which allows restricting what each personal access token can do separately. There are two approaches that could have been used for this: * Multiple authorizations (this approach) * Single authorization The issue with the single authorization approach is that it is more complex, because we would need to ensure at all times that personal access token authority does not exceed account authority. I think such an approach is risky unless the account access policy is immutable, and even though, it's more complex as you have to write a verifier to compare personal access token permissions with account permissions to ensure authority is not exceeded. With the multiple authorization approach, most of that complexity goes away, though it does require two authorization queries instead of one. It doesn't matter if the personal access token permissions exceed the account permissions, because the account permissions will be checked first, and if the request is not authorized for the account, it will be rejected before even checking the personal access token permissions. One issue I found is that you cannot delete a project using a personal access token, because the personal access token's access/applied tags are considered dependencies, and you cannot delete a project with dependencies. Maybe we want the code to automatically handle this case? To keep the api specs passing, this grants admin permissions to the personal access token used by default. However, it adds a couple of tests using non-admin personal access tokens, one to test the success case and one to test the failure case.
3.4 KiB
3.4 KiB