Capabilities
@nocobase/app-plugin-authorization provides permission sets, page and settings access, business actions, and database field, record and relation policies.
The application declares resources and management UI; the plugin supplies authorization decisions and data policies.
Configure access
| Object | Controls |
|---|---|
| Permission set | Grants assigned to users or other subjects |
page | Opening a page |
settings | Reading or changing an administration surface |
composite | A business action and its underlying data operations |
database.collection | Policies for a Collection registered with authorization |
Resources and actions must be declared. A table's existence does not register its Collection with the permission model.
The configured root permission set is unrestricted and should be distinct from ordinary business roles. Current account creation assigns Member explicitly; it is not an unavoidable implicit permission for every signed-in user.
Scenarios and examples
Example: viewing and editing orders
- Declare view and edit capabilities, including fields and record selections.
- Grant support staff view access and responsible users the required edit access.
- Use route
authzanduseCanfor navigation and buttons; check the operation again in the API. - Apply record and field policies through public methods such as
authz.database.policyFor(...)orauthorizeRepository(...). - Verify lists, details, relations and direct API calls with different roles.
An operation check followed by an unrestricted query loses record and field restrictions. Hiding navigation is not server authorization.
Development prompt (for a Coding Agent working in the application directory):
Use Authorization to add order view and edit access. Declare pages and business
actions, reuse existing roles, and do not add root or unrestricted grants.
Control UI actions and enforce server-side operation, record and field policies.
Test lists, details, relations and direct API calls as read-only, editing and denied users.Done whenRead-only users can read allowed orders but cannot edit; other records and restricted fields stay inaccessible.
Key principles and implementation
These are the integration areas and expected interface changes for this example. They describe development work; use the actual file layout of your application.
| Integration area | Code or configuration change | UI and behavior change |
|---|---|---|
| Authorization config and resource declarations | Register Collections, actions and field dependencies | Management choices reflect business capabilities |
| Business services and Repository queries | Apply returned authorization policies | Lists, details and writes enforce the same boundaries |
| Page routes and controls | Use authz and useCan, retaining API enforcement | UI access reflects the role |
Integration and entry points
Register Client and Server plugins after Authentication, then apply migrations and seeds. Compose configuration in server/config/authorization.ts; resolve authorizationToken from /server for trusted server integration.
The plugin exposes /api/authorization, AuthorizationClient and hooks such as useCan. The application builds its permission management pages and declares grantable business capabilities.
Record-access extensions
- Default data access adds a shared record baseline to an already granted action.
- Sharing rules adds selected records for named subjects.
- Restriction rules narrows the records those subjects may still access.
None grants an action. Management UI grouping also has no authorization effect. See Manage plugins for installation.
AI development constraints and verification
Plugin-specific development constraints
- Declare capabilities before granting them; database queries outside the permission model are not protected by those grants.
- Check pages, actions, fields, records and relations, not just a boolean can result followed by unrestricted queries.
- Use ordinary roles and direct API requests; review role seed changes for unintended expansion of existing access.
These are acceptance requirements for your integration, not claims of completed live verification. Ask the Agent to report actual changes, executed checks and unverified items. See Continue developing your app and Testing for project guidance, Skills and shared checks.