ekklesiaandClaude Opus 5
c8fa13dd6a
A fresh production installation deadlocked. ADR 0034 gave Ekklesia a login
page and ADR 0019 gave it a single-use platform-owner bootstrap, but that
bootstrap grants ownership to a user id that already exists and has no way
to bring one into being. Public signup is disabled by default and
production cannot enable it at all, so a newly deployed instance had a
login page, no account, and no supported way to create one — only hand-
written SQL or briefly opening public registration.
pnpm identity:create-initial-owner -- --email [email protected]
creates the identity and grants it ownership, in the same shape as the
other operator commands: trusted local tooling, reachable only by someone
who already holds the database credentials, serving no HTTP route. No
/signup, /register, or /setup route is added, no bootstrap endpoint, and
no setup token; public signup stays disabled in every environment and a
test asserts a freshly bootstrapped deployment still refuses
/api/auth/sign-up/email.
The identity is created through Better Auth's own sign-up path, so
hashing, salting, normalization and the 8-128 bound are the identity
system's rather than a second implementation that could drift. Because the
server's instance refuses account creation, the command builds its own
in-process instance; nothing in apps/api imports it and the running
server's posture is untouched.
The sign-up result is verified rather than trusted. Better Auth returns a
fabricated success for an already-registered address — a user object whose
id was never persisted, database unchanged. That is correct enumeration
defence on a public endpoint and a trap here, so the identity is always
read back from the database and that read, not the response, is what the
grant uses.
An existing usable identity is adopted: ownership is granted and its
password left alone, reported as an adoption rather than a creation. This
is the recovery path for the one partial failure possible, since sign-up
commits on Better Auth's connection and the grant is a separate
transaction. A credential-less row is refused instead — making it an owner
would consume the single use on an identity nobody can authenticate as. A
password is never reset and an account is never taken over.
Whole invocations are serialized by an advisory lock on their own key, so
a race cannot leave a stray signable-in account behind; the grant's own
locked single-use transaction is unchanged. There is no --force or reset.
The password is prompted for invisibly or read from stdin, never from
argv (--password is refused with an explanation) and never from an
environment variable, so nothing about it becomes permanent deployment
configuration. The command needs DATABASE_URL and nothing else — verified
that sign-up needs no secret, base URL, or trusted origins, and that the
resulting account signs in through a separately configured server — so the
first owner can be created before TLS or DNS exist. It never migrates.
Proven end to end rather than at the database: a fresh installation is
bootstrapped, signed in through the real browser login transport with
signup disabled, its principal read, and used to open an owner-protected
resource that stays closed to anonymous callers.
Co-Authored-By: Claude Opus 5 <[email protected]>
41 lines
1.8 KiB
TypeScript
41 lines
1.8 KiB
TypeScript
import { describe, expect, it, vi } from "vitest";
|
|
|
|
const poolConstructor = vi.hoisted(() => vi.fn());
|
|
|
|
vi.mock("pg", () => ({ Pool: poolConstructor }));
|
|
|
|
describe("create-initial-owner CLI import safety", () => {
|
|
const originalEnv = { ...process.env };
|
|
|
|
it("does not read DATABASE_URL, connect to PostgreSQL, or create anything merely by importing the module", async () => {
|
|
delete process.env.DATABASE_URL;
|
|
|
|
// Under Vitest, process.argv[1] is never this file's own path, so isDirectExecution() is false
|
|
// exactly as it is for `bootstrap-platform-owner.ts` — no argv manipulation is needed to prove
|
|
// the guard holds. Importing the command must never prompt, connect, or write.
|
|
await expect(import("../src/cli/create-initial-owner.js")).resolves.toBeDefined();
|
|
|
|
expect(poolConstructor).not.toHaveBeenCalled();
|
|
|
|
process.env = originalEnv;
|
|
});
|
|
|
|
it("reads no environment variable for the password", async () => {
|
|
// The password is prompted for or read from standard input; it is deliberately never taken from
|
|
// the environment, so nothing can make it permanent deployment configuration. Asserted against
|
|
// the source rather than behaviour, because the absence of a lookup is what matters.
|
|
const source = await import("node:fs/promises").then((fs) =>
|
|
fs.readFile(new URL("../src/cli/create-initial-owner.ts", import.meta.url), "utf8"),
|
|
);
|
|
|
|
const environmentReads = [...source.matchAll(/process\.env\.([A-Z_]+)/gu)].map(
|
|
(match) => match[1],
|
|
);
|
|
expect(environmentReads).toEqual(["DATABASE_URL"]);
|
|
// No dynamic lookup either, which a named-property scan alone would miss.
|
|
expect(source).not.toMatch(/process\.env\[/u);
|
|
// And a password supplied on the command line is refused rather than quietly honoured.
|
|
expect(source).toContain("--password is not supported");
|
|
});
|
|
});
|