RBAC
Design and run permissions in ZopNight: one policy table that grows as the product does, three roles that come with it, roles you build yourself, and scoping people to their own team's resources.
6 lessons. 1 quiz.
Read in order, or jump to what you need.
The policy table
By the end of this lesson, you will be able to identify the core entities in ZopNight's RBAC policy table, map any product surface to the policy it enforces, and explain why the gateway is the single enforcement point.
System roles: Viewer, Editor, Admin
By the end of this lesson, you will be able to describe the three system roles, match a job function to the right system role, and recognize when a system role does not fit and a custom role is warranted.
Custom roles
By the end of this lesson, you will be able to decide when a custom role is justified, design a custom role from the policy table, and avoid the common anti-patterns that turn custom roles into a maintenance burden.
Team-scoped access
By the end of this lesson, you will be able to configure team-scoped access using the `allResources` and `resourceIds` fields, distinguish team scoping from role scoping, and reason about the three-state scope model (nil / empty / list).
The three-state scope model
By the end of this lesson, you will be able to predict the query behavior of each scope state (nil / empty / list), explain why the empty state is a distinct concept rather than a degenerate case, and identify which state any given user is in.
Frontend gating with usePermission()
By the end of this lesson, you will be able to recognize how ZopNight's frontend gates UI based on RBAC, distinguish the frontend gate (UX) from the gateway check (security), and reason about what happens when the two disagree.
Module quiz.
Take it once the lessons are done.