james
0ceb4a2b25
Wave 2 of replacing the fixed-data mock adapter: the auth domain joins the live list, so credentials, roles and tokens belong to the real user. - session: validate a restored token through /auth/me instead of trusting localStorage, clearing it on 401/403 but keeping it when the API is merely unreachable; the route guard now uses the validated session - login: report a 401 as invalid credentials rather than a generic failure, and drop the 6-character client rule so the API owns the password policy - register: raise the rule to the API's 8 characters, remove the verification-code field (its button only counted down and the value was never sent), and report a duplicate email (409) distinctly - TopBar and the user profile render their session-dependent branch client-only: validating the session before hydration made those localStorage-backed branches report hydration mismatches the previous code did not Verified against the running backend: wrong password rejected, real JWT issued, /user reachable, a short password refused with no network call, duplicate email reported, a tampered token cleared and bounced to sign-in, a stale token kept when the API is down, and the fixed-data rollback still signs in with the backend stopped. Also re-cuts docs/TBD-migrate-wave.md: auth is done, and cart, orders, shipments and invoices must move together, because the mock adapter keeps their state in one shared object and a partial flip fails at checkout. OpenSpec change: openspec/changes/replace-mock-api-wave-2
2.9 KiB
2.9 KiB
Tasks
1. Adapter and configuration
- 1.1 Add
authto the defaultliveDomainsinapps/mall/nuxt.config.tsand confirmLIVE_PICKS.authinapps/mall/plugins/api.tsalready coversregister/login/me; verify a sign-in request reaches:8080whilegetCartstill resolves from fixed data - 1.2 Confirm the rollback path: with
NUXT_PUBLIC_LIVE_DOMAINSset to catalog and currency only, sign-in returns the fixed demo user again; verify by signing in with any password
2. Session and route guard
- 2.1 Add a session action that validates a restored token through
$api.me(), clearing the stored session and returning to sign-in on 401/403 but leaving the session intact when the API is merely unreachable; verify with a tamperedvmall.tokenand again with the backend stopped - 2.2 Make
middleware/auth.tsrely on the validated session rather thanlocalStoragealone; verify a shopper with a stale token lands on/loginwhile a valid one reaches/user - 2.3 Render the session-dependent header and profile name client-only (
components/shell/TopBar.vue,pages/user.vue); added during implementation because validating the session before hydration made thoselocalStorage-backed branches report hydration mismatches that the pre-change code did not; verified by A/B that the sign-in flow now produces no mismatch warnings
3. Sign-in panel
- 3.1 Map failures on
ApiError.status/codeso a 401 reports invalid credentials rather than the current generic message, adding the key toapps/mall/locales/auth.tsin en and zh (the per-domain module behindlocales-extra.ts); verify with a deliberately wrong password
4. Registration panel
- 4.1 Raise the client password rule to 8 characters with its own message; verify a 7-character password is refused without any network call.
apps/mall/pages/forgot-password.vuewas aligned to the same rule because it shares thevalidationPasswordmessage - 4.2 Remove the verification-code field and its countdown so the form no longer requires it; verify registration submits with display name, email and password only
- 4.3 Report a duplicate email (409) distinctly from other failures, adding the key to
apps/mall/locales/auth.tsin en and zh; verify by registering an address that already exists
5. Verification
- 5.1 Run
pnpm --filter @vmall/mall buildand confirm it passes - 5.2 With the backend running and seeded, verify in a browser: sign in as
customer@vmall.local, see the utility-bar welcome/sign-out state, reach/user, and confirm the only console entries are the deliberately triggered 401/409 responses plus a pre-existing hydration warning on the unauthenticated/userredirect (A/B verified identical before this change) - 5.3 With every domain set to fixed data and the backend stopped, verify sign-in and browsing still work, so the rollback path is intact