Skip to content

debugging: add a header to all responses for debugging rbac checks #474

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

Closed
aslilac opened this issue Mar 11, 2025 · 0 comments
Closed

debugging: add a header to all responses for debugging rbac checks #474

aslilac opened this issue Mar 11, 2025 · 0 comments
Assignees

Comments

@aslilac
Copy link
Member

aslilac commented Mar 11, 2025

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
@aslilac aslilac self-assigned this Mar 11, 2025
@aslilac aslilac closed this as completed Apr 10, 2025
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

1 participant