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]>
80 lines
2.1 KiB
JSON
80 lines
2.1 KiB
JSON
{
|
|
"name": "@ekklesia/core",
|
|
"version": "0.1.0",
|
|
"private": true,
|
|
"type": "module",
|
|
"files": [
|
|
"dist"
|
|
],
|
|
"exports": {
|
|
".": {
|
|
"types": "./dist/index.d.ts",
|
|
"import": "./dist/index.js"
|
|
},
|
|
"./modules": {
|
|
"types": "./dist/modules/index.d.ts",
|
|
"import": "./dist/modules/index.js"
|
|
},
|
|
"./storage": {
|
|
"types": "./dist/storage/index.d.ts",
|
|
"import": "./dist/storage/index.js"
|
|
},
|
|
"./dashboard": {
|
|
"types": "./dist/dashboard/index.d.ts",
|
|
"import": "./dist/dashboard/index.js"
|
|
},
|
|
"./migrations": {
|
|
"types": "./dist/migrations/index.d.ts",
|
|
"import": "./dist/migrations/index.js"
|
|
},
|
|
"./diagnostics": {
|
|
"types": "./dist/diagnostics/index.d.ts",
|
|
"import": "./dist/diagnostics/index.js"
|
|
},
|
|
"./identity": {
|
|
"types": "./dist/identity/index.d.ts",
|
|
"import": "./dist/identity/index.js"
|
|
},
|
|
"./authorization": {
|
|
"types": "./dist/authorization/index.d.ts",
|
|
"import": "./dist/authorization/index.js"
|
|
},
|
|
"./database": {
|
|
"types": "./dist/database/index.d.ts",
|
|
"import": "./dist/database/index.js"
|
|
},
|
|
"./devices": {
|
|
"types": "./dist/devices/index.d.ts",
|
|
"import": "./dist/devices/index.js"
|
|
}
|
|
},
|
|
"scripts": {
|
|
"build": "tsc --project tsconfig.build.json",
|
|
"identity:migration:generate": "drizzle-kit generate --config=drizzle.config.ts",
|
|
"identity:schema:generate": "auth generate --config=identity-schema-generator.config.ts --output=.identity-schema-reference.ts -y",
|
|
"lint": "biome lint .",
|
|
"test": "vitest run",
|
|
"typecheck": "tsc --noEmit --project tsconfig.json"
|
|
},
|
|
"dependencies": {
|
|
"@aws-sdk/client-s3": "3.1116.0",
|
|
"@aws-sdk/s3-request-presigner": "3.1116.0",
|
|
"@ekklesia/contracts": "workspace:*",
|
|
"better-auth": "1.6.23",
|
|
"drizzle-orm": "0.45.2",
|
|
"pg": "8.22.0"
|
|
},
|
|
"devDependencies": {
|
|
"@biomejs/biome": "2.5.3",
|
|
"@types/node": "24.13.3",
|
|
"@types/pg": "8.20.0",
|
|
"auth": "1.6.23",
|
|
"drizzle-kit": "0.31.10",
|
|
"typescript": "7.0.2",
|
|
"vitest": "4.1.10"
|
|
},
|
|
"ekklesia": {
|
|
"layer": "core"
|
|
}
|
|
}
|