pastilhasandClaude Opus 5
69a31051ac
POST /api/users plus an Add-account form in Settings > User management. Until now createUser had one call site — bootstrap, gated on an empty user table — so every non-owner account anywhere had been inserted into Postgres by hand. Created accounts are Active. The column defaults to Unverified and signin refuses anything else with a bare UNAUTHORIZED, which is exactly what made the hand-INSERT route look like a wrong password. Also closes a hole found while reading the write path: a second Super Admin was storable. The CHECK constraint pins user 1's role but cannot see other rows, and getOwnerUser() was LIMIT 1 with no ORDER BY, so two holders would have made "who owns this server" a question the query plan answered — and that answer feeds the agent sidecar's identity, vault access and origin scoping. Both write paths now refuse the role and getOwnerUser() orders by id. USER_DIRS and provisionUserDirs move into data-path.ts so the create handler and scripts/provision-user-dirs.ts cannot disagree about what an account's skeleton is. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
58 lines
2.4 KiB
TypeScript
58 lines
2.4 KiB
TypeScript
// Create the per-user root under DATA_PATH for the given accounts.
|
|
//
|
|
// bun scripts/provision-user-dirs.ts a@b.com c@d.com
|
|
// DRY_RUN=1 bun scripts/provision-user-dirs.ts a@b.com
|
|
//
|
|
// Takes emails as arguments rather than reading the user table: the directory layout does not depend
|
|
// on the database, and keeping the DB out means this runs with nothing else up. At invite time the
|
|
// caller already knows the email.
|
|
//
|
|
// This is the directory skeleton ONLY. It is deliberately not a revival of the old provision.ts, which
|
|
// also seeded shell rc files and wrote a generated CLAUDE.md + settings.json describing the user's
|
|
// Docker container. That architecture is gone. What survives from it is the useful part: a user has a
|
|
// root, and a home inside it.
|
|
//
|
|
// Idempotent — an existing directory is left exactly as it is, so re-running is safe.
|
|
|
|
import { mkdirSync, existsSync } from 'node:fs';
|
|
import { join } from 'node:path';
|
|
// The list and DATA_PATH itself come from the platform rather than being restated here. The owner's
|
|
// create-account handler provisions the same skeleton, and a script that drifted from it would produce
|
|
// accounts that differ by how they were made. Importing data-path.ts pulls in no database and no server.
|
|
import { DATA_PATH, USER_DIRS } from '../src/servers/data-path';
|
|
|
|
const DRY_RUN = process.env.DRY_RUN === '1';
|
|
const emails = process.argv.slice(2).filter(Boolean);
|
|
|
|
if (!emails.length) {
|
|
console.error('Usage: bun scripts/provision-user-dirs.ts <email> [email...]');
|
|
process.exit(2);
|
|
}
|
|
|
|
// A stray argument would create a junk directory next to real user roots, and it would look like a
|
|
// user. Cheap to refuse.
|
|
const invalid = emails.filter((e) => !/^[^\s@/]+@[^\s@/]+\.[^\s@/]+$/.test(e));
|
|
if (invalid.length) {
|
|
console.error(`Not valid email addresses: ${invalid.join(', ')}`);
|
|
process.exit(2);
|
|
}
|
|
|
|
console.log(`DATA_PATH = ${DATA_PATH}`);
|
|
console.log(`${DRY_RUN ? 'Would provision' : 'Provisioning'} ${emails.length} user root(s)\n`);
|
|
|
|
for (const email of emails) {
|
|
const root = join(DATA_PATH, email);
|
|
console.log(`${email}${existsSync(root) ? '' : ' [new root]'}`);
|
|
|
|
for (const dir of USER_DIRS) {
|
|
const path = join(root, dir);
|
|
if (existsSync(path)) {
|
|
console.log(` · ${dir} (exists)`);
|
|
continue;
|
|
}
|
|
if (!DRY_RUN) mkdirSync(path, { recursive: true });
|
|
console.log(` ${DRY_RUN ? '+' : '✓'} ${dir}`);
|
|
}
|
|
console.log('');
|
|
}
|