Repository navigation
Mount a grant check on every tenant route - #255
Merged
alexanderguy merged 7 commits intoNov 4, 2026
Merged
Conversation
Tenant details include the tenant config. The default member role holds read on every resource, so members keep access. Only principals whose roles lack that read lose it, and for them the admin UI tenant pages fail to load.
The request names any principal in the tenant and any consumer, and the response lists the grants that match. Without a grant check, any member could probe the access of every principal, run-token consumers included. The default member role holds read on every resource, so members keep access. Only roles without read on grants lose it.
No consumer reaches these routes today, because the git token middleware refuses run tokens. The required argument makes each caller state the consumer, so a later route cannot leave it out by omission, the same rule that the other grant checks follow.
Route registration never touches the database, so the check runs in the unit suite instead of only where Postgres is available.
The list route checks a fixed resource, so it needs nothing from the handler. As middleware, the check is visible on the route like every other fixed-resource grant check. A refusal now carries the shared grant-check message. Only the routes take requireGrant. resolveApproval keeps the narrower ResolveApprovalDeps, exported beside the route deps, so that a caller that resolves an approval directly does not have to supply it.
Grants are the only control on the hub API only if every tenant route checks one. A new tenant route without a grant check now fails the unit suite unless it is on the exemption list with a reason.
Member
Author
Self-Review (
|
alexanderguy
deleted the
intr-711-mount-a-grant-check-on-every-tenant-route
branch
November 4, 2026 06:37
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
/api/tenants/:tenantIdchecks a grant: tenant details requiretenant:<id>/read, grant evaluation requiresgrant:*/read, and the approval list checksapproval:*/resolveinrequireGrantmiddleware.requireGrantahead of its handler and no entry inGRANT_EXEMPTIONS. Each of the ten exemptions names its in-handler check and why the check is not middleware.docs/ROUTES.mdstates the rule.resolveAuthzVerdictrequires the consumer, like the other grant checks, and the run-token allow-list registration check runs in the unit suite.Verification
make allexits 0 with the Postgres-backed suites (10469, 254 and 1519 tests pass, 0 fail).*/reador more, so they keep access to tenant details and grant evaluation. A role without those reads gets 403.Closes INTR-711
Closes INTR-491