feat: integrate module authorization
Wires composePlatformPermissionRegistry into apps/api's production startup: startApi() discovers every installed module, composes the one immutable platform permission registry (Core's own declarations plus every module's), and only then constructs the shared PostgreSQL pool, Better Auth, and the HTTP server. A discovery or composition failure — an invalid manifest, a reserved core.* namespace claim, or a duplicate declaration — propagates before anything exists to close; there is no Core-only registry fallback. apps/api/src/platform-permissions.ts resolves the repository root from its own file location, never process.cwd(), so package-scoped test runs discover the right modules/ directory. createApiApp/createGrantsRoutes now require the composed registry as an injected authorization option, replacing the previous hard-coded CORE_PERMISSION_REGISTRY; requirePermission continues to work identically for Core-owned and module-owned permissions, since it has no concept of the distinction. Extends pnpm doctor with a modules.permissions check (reusing the already-discovered module list, distinguishing reserved-namespace from generic-duplicate failures, never re-discovering modules) and pnpm modules:validate to compose the same registry before a module is considered installable. Adds focused coverage: startup-ordering and failure-isolation tests in apps/api/tests/lifecycle.test.ts, module-owned-declaration enforcement tests in apps/api/tests/authorization-middleware.test.ts, Doctor composition tests in core/tests/doctor.test.ts, and a live PostgreSQL end-to-end scenario proving a real installed module's permission is discoverable, grantable, and deniable once the module is absent again after a restart, without ever executing its server entrypoint.
This commit is contained in:
@@ -6,8 +6,9 @@ surfaces.
|
||||
|
||||
## Current status
|
||||
|
||||
Phase 3 is complete, and Phase 4A (Core identity foundation), Phase 4B (identity HTTP transport),
|
||||
and Phase 4C (Core authorization) have landed. The repository includes
|
||||
Phase 3 is complete; Phase 4A (Core identity foundation), Phase 4B (identity HTTP transport), and
|
||||
Phase 4C (Core authorization) have landed; and Phase 5A (module authorization integration) is in
|
||||
progress. The repository includes
|
||||
public module contracts, independently versioned capabilities, static module manifests,
|
||||
deterministic automatic discovery, compiled server loading, a staged capability registry,
|
||||
dependency-ordered lifecycle with rollback, module-owned Drizzle table contracts, deterministic
|
||||
@@ -46,11 +47,22 @@ immutable permission registry; an explicit, single-use, concurrency-safe platfor
|
||||
command (`pnpm authorization:bootstrap-owner`, never HTTP-exposed, never inferred from signup
|
||||
order); and, in `apps/api`, reusable Hono authorization enforcement plus a narrowly scoped
|
||||
`/api/v1/grants` HTTP API for managing *explicit* grants only, requiring an exact trusted `Origin`
|
||||
on every mutation. Roles/groups/teams/tenants, an owner-management HTTP endpoint, service
|
||||
accounts/API tokens, and module-permission registration remain later work. See
|
||||
[Authorization](docs/development/authorization.md) and
|
||||
on every mutation. Roles/groups/teams/tenants, an owner-management HTTP endpoint, and service
|
||||
accounts/API tokens remain later work. See [Authorization](docs/development/authorization.md) and
|
||||
[ADR 0013](docs/architecture/decisions/0013-core-authorization-and-owner-bootstrap.md).
|
||||
|
||||
Phase 5A (in progress) wires module-declared permissions into that same authorization system: a
|
||||
version-3 module manifest declares permissions as complete `{id, baseline, description}`
|
||||
declarations (never a bare string), and `apps/api` discovers every installed module and composes
|
||||
one immutable platform permission registry — Core's own declarations plus every module's — before
|
||||
constructing its database pool, Better Auth instance, or HTTP server. A module's declared
|
||||
permission is then enforceable and grantable through the exact same `requirePermission` middleware
|
||||
and `/api/v1/grants` HTTP API Core's own permissions already use, with `core.*` reserved and never
|
||||
claimable by a module. `pnpm doctor` and `pnpm modules:validate` both validate permission
|
||||
composition. Module HTTP route registration and relationship-derived grant creation remain later
|
||||
work. See [Authorization](docs/development/authorization.md#module-permission-composition) and
|
||||
[Module development](docs/module-development/README.md).
|
||||
|
||||
## Quick start
|
||||
|
||||
Prerequisites: Node.js 24 LTS, pnpm 11.12, and Docker with Compose.
|
||||
@@ -89,6 +101,8 @@ Modules
|
||||
0 modules installed
|
||||
✓ Dependency graph valid
|
||||
Dependency order is empty.
|
||||
✓ Permission registry composed
|
||||
1 permission registered
|
||||
|
||||
Data definitions
|
||||
✓ Schemas validated
|
||||
|
||||
Reference in New Issue
Block a user