ekklesiaandClaude Opus 5
80189c8ae2
ADR 0033 gave Ekklesia a display host and ADR 0034 gave it a login page. Together, the only way to light a television in a foyer was to sign a human being into it and leave that session running on a screen anyone can walk up to: a person's credentials on a wall, a person's session as the thing signage depends on, and the display going dark when they are revoked or their session simply expires. A screen is not a person. Ekklesia now recognizes three principal classes — anonymous, authenticated human, and managed device — and a device is a first-class principal with its own credential and its own explicit permissions. It has no email, no password, and no row in the identity tables, and it satisfies the `authenticated` baseline never, so every route that settles for "somebody is signed in" stays closed to it. Device permissions live in their own table because ekklesia_core_grant.user_id is a non-null foreign key into the user table and making it polymorphic would rewrite the platform's central authorization record to serve one narrow case. That is a schema decision, not a second decision point: the evaluator gained one branch, so a device is allowed or denied by the same function, with the same deny-by-default, as anyone else — with no owner path it could reach and no baseline that stands in for a grant. The six-digit code is not the credential. It is printed across a screen in a public hallway, so it is treated as public: it identifies a request to an administrator and is worth nothing alone. Collecting the credential also requires a 256-bit claim secret held only in the requesting browser's HttpOnly cookie, and approving requires the restricted core.devices.manage permission. Without that split, reading a code off a wall would hand over the screen's identity. The permission a pairing asks for is read from the module's validated display declaration, never from the request, so a browser cannot ask to be granted core.devices.manage or another module's permission. Approval grants exactly that one permission. Credentials are stored only as SHA-256; the raw value exists in the Set-Cookie that issues it and the device's own cookie jar, and is never logged, returned in JSON, or placed in a URL. The cookie is HttpOnly, so the module display code running in that same page cannot read it. Revocation is a server-side column checked on every principal resolution, and re-pairing mints a new identity so an old credential can never come back. State transitions are conditional updates, so one code cannot be approved twice or claimed into two credentials under a race. /api/v1/principal still reports a device as anonymous: it is what the Dashboard uses to decide whether a person is signed in. Displays read their viewer from the descriptor instead, which already performed the authorization — so displays are descriptor-first while the Dashboard stays principal-first, and neither infers an identity by elimination. Proven end to end against real PostgreSQL and real HTTP: an unpaired screen shows a code, an owner approves it, the device opens the display descriptor and a realtime stream, and revocation closes both while the device still holds its cookie. An already-open SSE stream is bounded by realtime's existing five-minute reconnect rather than closed instantly, and that bound is documented rather than called immediate. Co-Authored-By: Claude Opus 5 <[email protected]>
63 lines
2.7 KiB
TypeScript
63 lines
2.7 KiB
TypeScript
import type { ModuleDatabase } from "@ekklesia/contracts";
|
|
import {
|
|
type AuthorizationDrizzleDatabase,
|
|
createAuthorizationDrizzleView,
|
|
} from "@ekklesia/core/authorization";
|
|
import {
|
|
createDashboardDrizzleView,
|
|
type DashboardDrizzleDatabase,
|
|
} from "@ekklesia/core/dashboard";
|
|
import { createValidatedPostgresPool, type PostgresPoolOptions } from "@ekklesia/core/database";
|
|
import { createDeviceDrizzleView, type DeviceDrizzleDatabase } from "@ekklesia/core/devices";
|
|
import { createIdentityDrizzleView, type IdentityDrizzleDatabase } from "@ekklesia/core/identity";
|
|
import {
|
|
createModuleConfigurationView,
|
|
createModuleDatabaseView,
|
|
createModuleLifecycleView,
|
|
type ModuleConfigurationDrizzleDatabase,
|
|
type ModuleLifecycleDrizzleDatabase,
|
|
} from "@ekklesia/core/modules";
|
|
|
|
export interface ApiDatabaseHandle {
|
|
readonly authorization: AuthorizationDrizzleDatabase;
|
|
readonly devices: DeviceDrizzleDatabase;
|
|
readonly dashboard: DashboardDrizzleDatabase;
|
|
readonly identity: IdentityDrizzleDatabase;
|
|
readonly module: ModuleDatabase;
|
|
readonly moduleConfiguration: ModuleConfigurationDrizzleDatabase;
|
|
readonly moduleLifecycle: ModuleLifecycleDrizzleDatabase;
|
|
/** Closes the one shared pool exactly once, regardless of how many typed views were created
|
|
* over it. Safe to call from both a startup-failure cleanup path and normal shutdown. */
|
|
readonly close: () => Promise<void>;
|
|
}
|
|
|
|
/**
|
|
* Composes the one physical PostgreSQL pool this process uses for Core's identity and
|
|
* authorization schemas plus the module database facade: one validated, timeout-bounded
|
|
* `pg.Pool` (`createValidatedPostgresPool`, `@ekklesia/core/database`), wrapped by independent
|
|
* typed Drizzle views (`createIdentityDrizzleView`, `createAuthorizationDrizzleView`,
|
|
* `createDashboardDrizzleView`, `createModuleLifecycleView`, `createModuleConfigurationView`,
|
|
* `createModuleDatabaseView`). No domain
|
|
* owns or closes the pool in this composition — `close()`
|
|
* here is the only thing that ever calls `pool.end()`. `createIdentityDrizzleDatabase`/
|
|
* `createAuthorizationDrizzleDatabase` remain available, unaffected, and independently testable
|
|
* for callers that only need one domain.
|
|
*/
|
|
export function createApiDatabase(
|
|
databaseUrl: string,
|
|
options: PostgresPoolOptions = {},
|
|
): ApiDatabaseHandle {
|
|
const { close, pool } = createValidatedPostgresPool(databaseUrl, options);
|
|
|
|
return Object.freeze({
|
|
authorization: createAuthorizationDrizzleView(pool),
|
|
close,
|
|
devices: createDeviceDrizzleView(pool),
|
|
dashboard: createDashboardDrizzleView(pool),
|
|
identity: createIdentityDrizzleView(pool),
|
|
module: createModuleDatabaseView(pool),
|
|
moduleConfiguration: createModuleConfigurationView(pool),
|
|
moduleLifecycle: createModuleLifecycleView(pool),
|
|
});
|
|
}
|