Webiny-js webiny-api-permissions
install
source · Clone the upstream repo
git clone https://github.com/webiny/webiny-js
Claude Code · Install into ~/.claude/skills/
T=$(mktemp -d) && git clone --depth=1 https://github.com/webiny/webiny-js "$T" && mkdir -p ~/.claude/skills && cp -r "$T/skills/user-skills/api/permissions" ~/.claude/skills/webiny-webiny-js-webiny-api-permissions && rm -rf "$T"
manifest:
skills/user-skills/api/permissions/SKILL.mdsource content
API Permissions
Overview
Permissions follow two layers: domain (schema) and features (DI abstractions + feature registration). Each package declares a permission schema and gets a typed
Permissions abstraction injectable into use cases via DI. Methods like canRead, canEdit, canDelete, canPublish, onlyOwnRecords replace manual identityContext.getPermission() calls.
Layer 1: Domain — Permission Schema
Define the schema in
src/domain/permissionsSchema.ts:
import { createPermissionSchema } from "webiny/api/security"; export const SM_PERMISSIONS_SCHEMA = createPermissionSchema({ prefix: "sm", fullAccess: true, entities: [ { id: "product", permission: "sm.product", scopes: ["full", "own"], actions: [{ name: "rwd" }, { name: "pw" }] }, { id: "settings", permission: "sm.settings", scopes: ["full"] } ] });
The schema MUST use
as const inference (handled by createPermissionSchema) for TypeScript to narrow entity IDs in method signatures.
Schema Fields
| Field | Description |
|---|---|
| Namespaces the DI abstraction: |
| for standard full access. Pass an object with custom boolean flags for full-access extras (e.g., ). |
| Entity identifier used in method calls: |
| Permission name matched against identity permissions |
| or — determines if own-scope supported |
| Action definitions — built-in: , ; custom: boolean flags |
Scopes
— User can access all records (default when no"full"
flag on permission object)own
— User can only access records where"own"createdBy.id === identity.id
Simple Apps (No Entities)
Omit
entities for binary full/no access:
export const MA_PERMISSIONS_SCHEMA = createPermissionSchema({ prefix: "ma", fullAccess: true });
Layer 2: Features — DI Artifacts + Registration
Abstraction (src/features/permissions/abstractions.ts
)
src/features/permissions/abstractions.tsimport { createPermissionsAbstraction } from "webiny/api/security"; import type { Permissions } from "webiny/api/security"; import { SM_PERMISSIONS_SCHEMA } from "~/domain/permissionsSchema.js"; export const SmPermissions = createPermissionsAbstraction(SM_PERMISSIONS_SCHEMA); export namespace SmPermissions { export type Interface = Permissions<typeof SM_PERMISSIONS_SCHEMA>; }
Feature (src/features/permissions/feature.ts
)
src/features/permissions/feature.tsimport { createPermissionsFeature } from "webiny/api/security"; import { SM_PERMISSIONS_SCHEMA } from "~/domain/permissionsSchema.js"; import { SmPermissions } from "./abstractions.js"; export const SmPermissionsFeature = createPermissionsFeature(SM_PERMISSIONS_SCHEMA, SmPermissions);
Registration
Register the feature in your context plugin:
import { SmPermissionsFeature } from "~/features/permissions/feature.js"; // In createContext: SmPermissionsFeature.register(container);
File Structure
src/ ├── domain/ │ └── permissionsSchema.ts # createPermissionSchema() ├── features/ │ └── permissions/ │ ├── abstractions.ts # createPermissionsAbstraction() + namespace type │ └── feature.ts # createPermissionsFeature() └── index.ts # SmPermissionsFeature.register(container)
Permission Methods
All methods follow a 3-tier bypass:
→identityContext.hasFullAccess()
permission (super admin)name: "*"
→ wildcard permission (e.g.hasFullSchemaAccess()
)"sm.*"- Entity-level permission check
Method Reference
| Method | Purpose | Item-aware | Notes |
|---|---|---|---|
| General access check | Yes | Without item: checks entity permission exists. With item + : checks |
| List filter flag | No | Returns when ALL permissions have |
| Read permission | No | Checks includes (or no = unrestricted) |
| Create permission | No | Checks includes |
| Edit permission | Yes | With + no item → allows (new/unsaved). With item → checks ownership |
| Delete permission | Yes | With + no item → RETURNS FALSE. Must pass item |
| Publish permission | No | Checks includes |
| Unpublish permission | No | Checks includes |
| Custom boolean action | No | Checks |
All return
Promise<boolean>. Entity IDs are fully typed — canRead("bogus") produces a type error.
OwnableItem Interface
interface OwnableItem { createdBy?: { id: string } | null; }
Use Case Implementation Patterns
Get Use Case (Read + Ownership Gate)
The Get use case is the central ownership gate — mutation use cases that delegate to GetById inherit ownership enforcement automatically.
import { Result } from "webiny/api"; import { GetByIdUseCase as UseCaseAbstraction, GetByIdRepository } from "./abstractions.js"; import { SmPermissions } from "~/features/permissions/abstractions.js"; import { NotAuthorizedError } from "~/domain/errors.js"; class GetByIdUseCaseImpl implements UseCaseAbstraction.Interface { constructor( private permissions: SmPermissions.Interface, private repository: GetByIdRepository.Interface ) {} async execute(id: string): UseCaseAbstraction.Return { // 1. Entity-level read check if (!(await this.permissions.canRead("product"))) { return Result.fail(new NotAuthorizedError()); } // 2. Fetch const result = await this.repository.execute(id); if (result.isFail()) { return result; } // 3. Item-level ownership check if (!(await this.permissions.canAccess("product", result.value))) { return Result.fail(new NotAuthorizedError()); } return result; } } export const GetByIdUseCase = UseCaseAbstraction.createImplementation({ implementation: GetByIdUseCaseImpl, dependencies: [SmPermissions, GetByIdRepository] });
List Use Case (Read + Own Records Filter)
import { IdentityContext } from "webiny/api/security"; class ListUseCaseImpl implements UseCaseAbstraction.Interface { constructor( private permissions: SmPermissions.Interface, private identityContext: IdentityContext.Interface, private repository: ListRepository.Interface ) {} async execute(params: UseCaseAbstraction.Params): UseCaseAbstraction.Return { if (!(await this.permissions.canRead("product"))) { return Result.fail(new NotAuthorizedError()); } const where = { ...params.where }; // Filter to own records if needed if (await this.permissions.onlyOwnRecords("product")) { const identity = this.identityContext.getIdentity(); where.createdBy = identity.id; } return this.repository.execute({ ...params, where }); } } // Dependencies must include IdentityContext dependencies: [SmPermissions, IdentityContext, ListRepository];
Important: The list
where type must include createdBy?: string. For CMS-based entities, CmsEntryListWhere already has this.
Update Use Case (Edit + Item-Level Check)
class UpdateUseCaseImpl implements UseCaseAbstraction.Interface { constructor( private permissions: SmPermissions.Interface, private getById: GetByIdUseCase.Interface, private repository: UpdateRepository.Interface ) {} async execute(id: string, data: UpdateData): UseCaseAbstraction.Return { // 1. Entity-level edit check (no item yet) if (!(await this.permissions.canEdit("product"))) { return Result.fail(new NotAuthorizedError()); } // 2. Fetch original (enforces canRead + canAccess via GetById) const getResult = await this.getById.execute(id); if (getResult.isFail()) { return getResult; } const original = getResult.value; // 3. Item-level edit check (defense in depth) if (!(await this.permissions.canEdit("product", original))) { return Result.fail(new NotAuthorizedError()); } // ... events + repository } }
Delete Use Case (CRITICAL: Item-Level Delete)
with canDelete
and no item returns own: true
.false
Unlike
canEdit (which returns true for own: true + no item), canDelete requires the item to verify ownership. The delete use case MUST fetch the item first.
class DeleteUseCaseImpl implements UseCaseAbstraction.Interface { async execute(params: Params): UseCaseAbstraction.Return { // Fetch first (enforces canRead + canAccess via GetById) const getResult = await this.getById.execute(params.id); if (getResult.isFail()) { return Result.fail(getResult.error); } const item = getResult.value; // Item-level delete check — MUST pass the item if (!(await this.permissions.canDelete("product", item))) { return Result.fail(new NotAuthorizedError()); } // ... events + repository } }
Publish Use Case (Publish + Ownership)
class PublishUseCaseImpl { async execute(params: Params): UseCaseAbstraction.Return { // 1. Entity-level publish check if (!(await this.permissions.canPublish("product"))) { return Result.fail(new NotAuthorizedError()); } // 2. Fetch (enforces ownership via GetById) const getResult = await this.getById.execute(params.id); if (getResult.isFail()) { return getResult; } // 3. Item-level ownership check (defense in depth) if (!(await this.permissions.canAccess("product", getResult.value))) { return Result.fail(new NotAuthorizedError()); } // ... events + repository } }
DI Injection
The permissions abstraction is passed directly as a dependency — it IS the DI key:
export const MyUseCase = UseCaseAbstraction.createImplementation({ implementation: MyUseCaseImpl, dependencies: [SmPermissions, OtherDep] });
Note: Use
SmPermissions directly (not SmPermissions.Abstraction). The abstraction returned by createPermissionsAbstraction is the DI key itself.
Gotchas
without item +canDelete
=own: true
— Always pass the item tofalse
. Fetch first, then check.canDelete
without item +canEdit
=own: true
— Intentional: allows editing new/unsaved records.true
without item =canAccess
— Only checks entity-level access, not ownership.true- List where type — Ensure the
interface includeswhere
for own-scope filtering.createdBy?: string - Dependencies order — DI constructor params must match the
array order exactly.dependencies - Abstraction is the DI key — Use
directly in dependencies, notSmPermissions
.SmPermissions.Abstraction
Matching Admin-Side Permissions
The API schema and the admin-side
createPermissionSchema should use the same prefix, entity IDs, and action names. This ensures the permissions emitted by the admin UI are correctly evaluated by the API.
API: createPermissionSchema({ prefix: "sm", entities: [{ id: "product", permission: "sm.product", ... }] }) Admin: createPermissionSchema({ prefix: "sm", entities: [{ id: "product", permission: "sm.product", ... }] })
See webiny-admin-permissions for the admin-side implementation.
Related Skills
- webiny-admin-permissions — Admin-side permission UI and DI-backed permission checking
- webiny-api-architect — Architecture overview, Services vs UseCases, feature structure
- webiny-use-case-pattern — UseCase implementation, Result handling, decorators
- webiny-dependency-injection — Injectable services catalog