RBAC Console

AuthorizationPage — manage roles, claims & scopes

AuthorizationPage is the admin UI for the Authorization model. It renders the roles, the auto-seeded claims and the role→claim assignments your config defines, and lets a godmin edit them visually — including the row-level scope on each assignment. It's the human front-end to everything the claim-check middleware enforces.

It's a pure consumer of generated CRUD actions over the roles, claims and role_claims system tables. AuthorizationPage is a single self-contained page (a roles/filters sidebar plus a combined claims editor); RoleList, ClaimList and RoleClaimEditor are separately-exported standalone building blocks you can compose yourself for a custom layout — the page itself does not mount them. authorizationPageTheme / extendAuthorizationPageTheme are exported design tokens, but they are not a way to re-skin the shipped UI: AuthorizationPage renders with its own fixed Tailwind styling (a hardcoded min-h-screen container) and never reads the theme, and no shipped component accepts a theme prop — the standalone panels read authorizationPageTheme but hardcode the default. Use the theme object only as reference tokens when you build an entirely custom layout yourself and drive its useAuthorizationStore directly.

Wiring the console#

AuthorizationPage takes typed actions for roles, claims and role-claims. Note the claim-assignment create MUST be the BULK role_claims create (BULK_ADD_ROLE_CLAIMS): AuthorizationPage always POSTs an array payload ([{ roleId, claimId }]) to addRoleClaimAction, so the single-create ADD_ROLE_CLAIM (which expects one object) fails at runtime — role_claims has bulk endpoints enabled, so use its /roleClaims/bulk key (the generated route prefix is the camelCased table name). Role creation, by contrast, sends a single object, so addRoleAction is the single-create ADD_ROLE. The two update actions (updateRoleAction, updateRoleClaimAction) are optional. Omitting updateRoleAction hides the role-description edit pencil. Omitting updateRoleClaimAction does NOT hide the scope-edit UI — the '+ Add scope filter' block still renders on every assignment; it only disables persistence, so the Save button becomes a silent no-op. Roles can still be created/deleted and claims toggled.

Every write requires a godmin acting session

The backend hard-locks the roles, claims, user_roles and role_claims tables: in the generic entity CRUD onBeforeHandle guard, any non-GET/HEAD/OPTIONS request to these four tables returns HTTP 403 'Forbidden: managing roles and claims requires godmin privileges' unless the acting session is godmin (verified x-user-roles header, or an authoritative DB role lookup fallback). So if you wire this page for a non-godmin admin role, the UI controls still render but create-role, delete-role, claim-toggle (BULK add / delete role_claims) and scope-save (update role_claims) all 403. This is about the ACTING user — distinct from the 'The godmin role is protected' callout below, which is about godmin as an edit target. The gate is independent of the claim model: even a role holding a generic post/put/delete claim on these tables is denied.

app/admin/authorization/page.tsx

1import { AuthorizationPage } from "nucleus-core-ts/fe";2import { useApiActions } from "@/lib/api";3 4const a = useApiActions();5 6<AuthorizationPage7  getRolesAction={a.GET_ROLES}8  addRoleAction={a.ADD_ROLE}9  deleteRoleAction={a.DELETE_ROLE}10  getClaimsAction={a.GET_CLAIMS}11  getRoleClaimsAction={a.GET_ROLE_CLAIMS}12  addRoleClaimAction={a.BULK_ADD_ROLE_CLAIMS}13  deleteRoleClaimAction={a.DELETE_ROLE_CLAIM}14  updateRoleClaimAction={a.UPDATE_ROLE_CLAIM}15  defaultMethodFilter="get"16/>;

role actionsgetRolesAction · addRoleAction · deleteRoleAction · updateRoleAction?Optional

Back the page's own roles sidebar — list, create and delete roles (update optional). Operate on the roles system table.

claim actionsgetClaimsActionOptional

Feeds the page's inline claims list — the full set of claims, mostly auto-seeded from your entities (get.product, post.order, get.product.price, …). Filterable by entity and HTTP method via defaultEntityFilter / defaultMethodFilter.

role-claim actionsgetRoleClaims · addRoleClaim · deleteRoleClaim · updateRoleClaim?Optional

Power the page's combined claims editor — toggle a claim onto the selected role and write the assignment. addRoleClaim MUST be the bulk role_claims create (BULK_ADD_ROLE_CLAIMS → POST /roleClaims/bulk): the page always POSTs an array [{ roleId, claimId }], so the single-create ADD_ROLE_CLAIM will not work here. updateRoleClaimAction persists scope edits.

callbacksonRoleCreated / onRoleDeleted / onClaimToggledOptional

Fire after each mutation so you can toast or refresh; the page already updates its own store optimistically.

presentationtitle / subtitle / className / defaultShowAssignedOnlyOptional

Optional presentational props: title (default 'Authorization Management'), subtitle, className, and defaultShowAssignedOnly (default false). defaultEntityFilter / defaultMethodFilter (both default 'all') seed the claim filters.

The three panels#

Three separately-exported standalone building blocks (the page does not itself mount them — compose them yourself for a custom layout).

RoleListroles + create/deleteOptional

Lists roles, selects the active one, and has an inline create form (name + description) and delete. Selecting a role drives the editor.

ClaimListbrowse claimsOptional

A read view of every claim in the system — the catalogue of permissions the entities generated, so you can see what's assignable.

RoleClaimEditortoggle + scopeOptional

For the selected role, toggles each claim on/off (writes/removes a role_claims row) and edits the scope string per assignment — including self: references for row-level ownership. This is the visual editor for the exact scopeFilters the backend applies.

Related sections

Authorization Auth Guard Frontend Components Ready-Made Actions