Skip to content

docs: document the permission-gating contract on hasPermission - #71

Open
Altamimi-Dev wants to merge 1 commit into
contextforge-org:mainfrom
Altamimi-Dev:64-document-permission-gating
Open

docs: document the permission-gating contract on hasPermission#71
Altamimi-Dev wants to merge 1 commit into
contextforge-org:mainfrom
Altamimi-Dev:64-document-permission-gating

Conversation

@Altamimi-Dev

Copy link
Copy Markdown
Contributor

Closes #64.

Documents the contract on hasPermission, the single symbol every client-side gate resolves to: the permission list comes from GET /rbac/my/permissions, which reflects role-derived grants only; the backend's is_admin bypass is invisible to the client. A DB is_admin user without the wildcard role fails the gates even though the API would serve the data. The note spells out that the gap fails closed, that the 403-based PermissionDenied layer cannot surface it (a fetch-gated card never fires the request), and what to check first when an admin is unexpectedly missing a card.

Two decisions worth flagging:

  • No shared "can this user see gated card X" helper for now: there are only two gates today and both are one-line hasPermission calls; the note lives at the one definition both resolve to. Easy to revisit once more gated cards land.
  • The root-cause fix (having get_user_permissions() reflect the effective permission set for is_admin users) belongs in IBM/mcp-context-forge and is not filed here.

GET /rbac/my/permissions returns role-derived grants only, so the
backend's is_admin bypass is invisible to client-side gates. Record the
gap, why it fails closed, and what to inspect first.

Signed-off-by: Ahmad Al Tamimi <altamimi.dev@gmail.com>
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

Successfully merging this pull request may close these issues.

Document the permission-gating contract

1 participant