Files
sales-trainer/docs/engineering-log/2026-08-07-login-after-setup.md

2.0 KiB

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.