No admin password recovery path: lose the one-time bootstrap line and the deployment is unreachable #208

New Issue

clawbot · 2026-08-20T05:48:21+02:00

clawbot commented

2026-08-20 05:48:21 +02:00

Bootstrap works and is documented (internal/database/database.go:193-264, README.md:243-246). Logging the plaintext once is intentional — #40 was closed on that basis and this issue does not reopen it.

The gap is what happens after. The password appears exactly once, as one line among roughly 45 fx PROVIDE/RUN/HOOK lines on stdout, and under docker run -d it goes to container logs subject to rotation. There is no reset path: no CLI subcommand (cmd/webhooker/main.go has no flags or subcommands at all), no forgot-password flow, no env override. Recovery today means hand-deleting the users row from webhooker.db so the next start re-seeds, which is documented nowhere.

Changing a known password works fine (verified: POST /user/admin/password succeeds). This is only about the lost case.

Definition of done:

a way to reset the admin password without a SQLite client — a webhooker resetpw subcommand (or equivalent) that takes the username, generates or accepts a password, and writes the Argon2id hash
it refuses to run against a DATA_DIR held by a live instance, per the locking issue filed alongside this one
README documents both the bootstrap line and the recovery command
the bootstrap line is made harder to lose: emit it with a visually distinct banner so it does not read as one more fx line
a test covers reset then login with the new password

Bootstrap works and is documented (`internal/database/database.go:193-264`, `README.md:243-246`). Logging the plaintext once is intentional — #40 was closed on that basis and this issue does not reopen it. The gap is what happens after. The password appears exactly once, as one line among roughly 45 fx `PROVIDE`/`RUN`/`HOOK` lines on stdout, and under `docker run -d` it goes to container logs subject to rotation. There is no reset path: no CLI subcommand (`cmd/webhooker/main.go` has no flags or subcommands at all), no forgot-password flow, no env override. Recovery today means hand-deleting the `users` row from `webhooker.db` so the next start re-seeds, which is documented nowhere. Changing a known password works fine (verified: `POST /user/admin/password` succeeds). This is only about the lost case. Definition of done: - a way to reset the admin password without a SQLite client — a `webhooker resetpw` subcommand (or equivalent) that takes the username, generates or accepts a password, and writes the Argon2id hash - it refuses to run against a `DATA_DIR` held by a live instance, per the locking issue filed alongside this one - README documents both the bootstrap line and the recovery command - the bootstrap line is made harder to lose: emit it with a visually distinct banner so it does not read as one more fx line - a test covers reset then login with the new password

clawbot added this to the 1.0.0 milestone 2026-08-20 05:48:21 +02:00

clawbot referenced this issue

2026-08-20 05:49:42 +02:00

1.0/mvp #33

clawbot referenced this issue

2026-08-20 06:23:16 +02:00

Lock DATA_DIR against a second instance (closes #201) #220

clawbot referenced this issue

2026-08-20 06:54:14 +02:00

Lock DATA_DIR against a second instance (closes #201) #220

clawbot referenced this issue

2026-08-20 07:07:11 +02:00