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
1.9 KiB
Spec Delta
MODIFIED Requirements
Requirement: Auth and buyer center
The mall SHALL provide B2B2C mall-style login, register and forgot-password panels backed by the live auth API, so credentials, roles and tokens belong to the real user rather than a fixed demo account. Registration SHALL require a password of at least 8 characters, matching the API's rule, and the register panel SHALL NOT ask for a verification code because no endpoint issues one. Failures SHALL be reported distinctly: invalid credentials on sign-in, and an already-registered email on registration. A token restored from storage SHALL be validated against the auth API on load, and a rejected token SHALL clear the session and return the shopper to sign-in. /user SHALL render a two-column buyer center with dashboard, order list/detail, addresses, favorites, coupons and invoices.
Scenario: sign in and inspect buyer data
- WHEN a shopper signs in with valid credentials and opens
/user - THEN the session carries the authenticated user, and the buyer-center shell and its fixed account/order/address/favorite/coupon/invoice data render
Scenario: wrong password rejected
- WHEN a shopper submits a password that does not match the account
- THEN sign-in fails with an invalid-credentials message and no session is established
Scenario: short password refused before the API call
- WHEN a shopper submits a registration password shorter than 8 characters
- THEN the panel asks for at least 8 characters without calling the API
Scenario: duplicate email reported
- WHEN a shopper registers an email that already has an account
- THEN the panel reports that the email is already registered rather than a generic failure
Scenario: rejected token clears the session
- WHEN a token restored from storage is rejected by the auth API
- THEN the stored session is cleared and the shopper is returned to sign-in