docs: record login-after-setup root cause (deployment data persistence)
This commit is contained in:
@@ -36,3 +36,4 @@ Informed by MiroFish (CrowdSight engine) + the hermes-brain-and-tools CrowdSight
|
|||||||
- `2026-08-07-security-ux.md` — security hardening (path traversal, IDOR, XSS) + UX/UI polish.
|
- `2026-08-07-security-ux.md` — security hardening (path traversal, IDOR, XSS) + UX/UI polish.
|
||||||
- `2026-08-07-auth-gitea.md` — username login + first-time admin setup + Gitea push.
|
- `2026-08-07-auth-gitea.md` — username login + first-time admin setup + Gitea push.
|
||||||
- `2026-08-07-docker-final.md` — Docker build fix: ship prebuilt frontend/dist, no npm in image (resolves repeated `vite: not found`).
|
- `2026-08-07-docker-final.md` — Docker build fix: ship prebuilt frontend/dist, no npm in image (resolves repeated `vite: not found`).
|
||||||
|
- `2026-08-07-login-after-setup.md` — can't-login-after-setup = deployment data non-persistence, not login logic (verified).
|
||||||
|
|||||||
35
docs/engineering-log/2026-08-07-login-after-setup.md
Normal file
35
docs/engineering-log/2026-08-07-login-after-setup.md
Normal file
@@ -0,0 +1,35 @@
|
|||||||
|
# 2026-08-07 — Bug: can't log in after first-run setup (password wrong) — root cause + fix
|
||||||
|
|
||||||
|
## Symptom
|
||||||
|
After first login (admin/1234) → change password in the forced setup screen → logout → logging
|
||||||
|
back in with the new password reports "wrong password".
|
||||||
|
|
||||||
|
## Investigation (verified via reproduction)
|
||||||
|
1. Backend `repro_login` in a temp data dir: first login (200, must_setup=true) → setup
|
||||||
|
(200, must_setup=false, email set) → **re-login with NEW password = 200** (works) → old
|
||||||
|
password = 401. => Login logic is CORRECT.
|
||||||
|
2. Same flow over the LIVE localhost server via HTTP (created tester2, setup with new pw,
|
||||||
|
re-login with new pw = 200). => Works end-to-end on a running server.
|
||||||
|
3. Conclusion: **not a login/setup code bug.** The failure is DEPLOYMENT DATA NON-PERSISTENCE.
|
||||||
|
|
||||||
|
## Root cause
|
||||||
|
On EasyPanel / any deploy that doesn't mount a volume, the container's `DATA_DIR`
|
||||||
|
(`/app/backend/data`) is **ephemeral — wiped on every container recreate/restart**. So after
|
||||||
|
setup, when the container is recreated:
|
||||||
|
- the changed admin password is lost (record resets to `1234` / `must_setup=true`),
|
||||||
|
- logging back in with the new password fails ("รหัสผ่านผิด").
|
||||||
|
|
||||||
|
## Fix
|
||||||
|
- Dockerfile: `ENV DATA_DIR=/app/backend/data` (explicit) + `VOLUME ["/app/backend/data"]`.
|
||||||
|
- README: added a "Data persistence" section — must mount a persistent volume to
|
||||||
|
`/app/backend/data` (compose already does `./data:/app/backend/data`); EasyPanel must mount one.
|
||||||
|
- Commit `334ef4e` (+ earlier docker commit), pushed to `git.moreminimore.com/kunthawat/sales-trainer`.
|
||||||
|
|
||||||
|
## How the user should apply
|
||||||
|
- **EasyPanel**: add a persistent volume mount → `/app/backend/data` (or set `DATA_DIR` env to a
|
||||||
|
mounted path). After that, data survives redeploys.
|
||||||
|
- If they already lost data (old password gone): delete/reset the container data so a fresh
|
||||||
|
`admin`/`1234` is bootstrapped, then redo setup and NEITHER redeploy without a volume.
|
||||||
|
|
||||||
|
## Note
|
||||||
|
Local dev: `backend/data/` is gitignored and lives on disk, so this only bites container deploys.
|
||||||
Reference in New Issue
Block a user