Files
familysync/.planning/phases/19-local-auth-no-oidc-mode/19-UAT.md
T

66 lines
3.5 KiB
Markdown

---
phase: 19-local-auth-no-oidc-mode
created: 2026-06-17T18:25:00Z
updated: 2026-06-17T18:25:00Z
status: pending
source: verification + plan-checkpoints
gaps: []
---
# Phase 19: Local Auth (No-OIDC Mode) — User Acceptance Tests
All automated verification passed (API 446/446, PWA 266/266, e2e desktop 42 passed
/ 3 skipped, typecheck clean; VERIFICATION.md status: passed, 21/21 must-haves).
The single blocker found during verification (admin reset-password URL mismatch) was
fixed and confirmed live (commit `53da4be`).
The items below are the remaining **human / live-stack** checks that cannot be driven
from the dev `DEV_AUTH_BYPASS` harness or a headless box. They do not block automated
goal achievement but should be confirmed before shipping.
## UAT Items
### 1. Login page visual + flow (real, non-bypass stack)
- **Test:** Run the stack with OIDC/Authelia configured and `DEV_AUTH_BYPASS` **off**.
Visit the app unauthenticated → confirm redirect to `/login`. Verify the brand slot
("FS" mark, "FamilySync", "Family calendar & lists"), the form (username auto-focus,
password show/hide), wrong-creds single error ("Incorrect username or password."),
correct-creds navigation into the app, and the OIDC button only when `oidcEnabled`.
- **Expected:** All surfaces per 19-UI-SPEC; no "Authelia" text anywhere; error copy
never blames a specific field.
- **Why human:** The unauth login-gate redirect is unreachable under the bypass-only
harness (covered at unit level in `App.test.tsx`); the full visual flow needs a real
browser against a non-bypass deployment. (Desktop/Chromium portions are already e2e-
covered via `login.spec.ts`.)
### 2. Admin Reset-password sheet (live, end-to-end)
- **Test:** As an admin, open Admin → Local Accounts → Reset password for a member;
submit a new password; confirm the member can then log in with it.
- **Expected:** `POST /api/admin/members/:id/password` returns 200; new password works.
- **Why human:** Needs a live stack with an admin session and a real local member.
(URL fix already verified: route reachable, 404 eliminated.)
### 3. Settings Change-password sheet (live, local user)
- **Test:** As a local user, Settings → Account → Change password; verify wrong current
password shows "Current password is incorrect.", correct current updates, and the new
password works on next login.
- **Expected:** Current-password verification enforced; update succeeds; re-login works.
- **Why human:** Needs a live stack with a local-user session.
### 4. Rate-limit / lockout test flakiness (harden)
- **Test:** Run `apps/api/tests/routes/localAuth.test.ts` Test 5 (10 failures → 423)
~10 times; characterize the intermittent failure the orchestrator observed (1 failure
across 3 runs, then stable).
- **Expected:** Stable pass; if timing-dependent, harden the in-memory rate-limit test
(e.g. fake timers / deterministic clock).
- **Why human:** Timing-dependent in-memory test; needs repeated runs to characterize.
### 5. CI harness green + D-15 image boundary (push, outward-facing)
- **Test:** Push the branch and open the PR so Gitea CI runs. Confirm the `harness` job
(iphone + pixel + desktop, incl. `login.spec.ts`) is green, the `api` job is green,
and the published-image hygiene checks (no `apps/api/scripts/` or `apps/pwa/e2e/` in
the prod image) pass.
- **Expected:** CI all green; no dev artifact in the shipped image (D-14/D-15).
- **Why human:** Pushing to the remote / triggering CI is an outward-facing action the
operator owns. (Plan 19-05's blocking checkpoint.)