docs: record login-after-setup root cause (deployment data persistence)

This commit is contained in:
Macky
2026-08-07 20:21:00 +07:00
parent 334ef4e00c
commit 7d778d780d
2 changed files with 36 additions and 0 deletions

View File

@@ -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).

View 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.