Description
Problem
Sometimes it can be hard to tell exactly what permissions checks are happening behind the scenes for any given API request. You can look at the code, but it can be a bit hard to hunt down (especially if you're not used to doing it), and even if you are it's very easy to overlook a check happening in a spot that you didn't expect. I know I've fallen victim to this a lot lately while working on tightening up permissions-related logic.
Proposed solution
A new response header detailing all of the rbac checks that happened during the request lifecycle.
It should look something like...
x-authz-checks: users.read=true
...where the true indicates that the authorization check succeeded (allowed the action)
A more complicated example might look something like...
x-authz-checks: templates.read=true; org:d0ce08d6-ca51-44bf-a77e-d08e547b3042::templates.update=false
...indicating that an initial check (can they read templates?) passed, but that a later check (can they update a template in this organization?) failed, helping to understand why a request may have responded with a 403. In a case like this, it's also important to note that it might not be exhaustive. The failed check likely stopped the request from being processed any further, and a successful request may have additional checks.
This should make it much easier to understand what permissions are necessary when trying to decide what checks should be performed on the frontend, and may also help spot odd/unnecessary/confusing checks happening in the backend.
Requirements
- Should be disabled by default in public releases, as it can leak a limited amount of information (mostly object ids)
- Should be enabled by default in testing builds, to make development easier and make this addition visible to our engineers
- Should use an unambiguous syntax to describe the checks which is simple to generate, but that is also mostly "obvious" to any human reader.
- Should use a header name prefixed with an
x-to indicate that it is non-standard