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
27 lines
1.9 KiB
Markdown
27 lines
1.9 KiB
Markdown
# 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
|