docs: add admin method toggle + error handling to email/phone login spec
Some checks failed
Architecture Governance / architecture (push) Has been cancelled
Some checks failed
Architecture Governance / architecture (push) Has been cancelled
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
@@ -138,7 +138,19 @@ Response (on success): {
|
||||
|
||||
The success response must be shaped identically to the existing `AuthSession` (`sessionId, userId, username, displayName, active, expires`, §2a's client model) — this lets every existing downstream consumer (guards, session signals, cart/checkout) work unchanged regardless of which mechanism produced the session.
|
||||
|
||||
Rate limiting/expiry, explicit so nothing is left to guesswork: 60s resend cooldown per identifier between `/request` calls; code expires 10 minutes after issuance; `requestId` is single-use (a `/verify` call consumes it on success or failure — a fresh `/request` is needed after either).
|
||||
Rate limiting/expiry, explicit so nothing is left to guesswork: 60s resend cooldown per identifier between `/request` calls; code expires 10 minutes after issuance; `requestId` allows up to 5 verify attempts before it's invalidated (consumed on success, on the 5th wrong attempt, or on expiry) — not single-use-per-attempt, so one mistyped digit doesn't force a full 60s wait for a new code.
|
||||
|
||||
**Error responses must use the existing envelope** (§5), with these codes on `/verify` (the client maps each to distinct UX — see the design doc):
|
||||
|
||||
| `error.code` | HTTP status | Meaning |
|
||||
|---|---|---|
|
||||
| `VALIDATION_FAILED` | 422 | Malformed identifier (`error.details[0]` names the field). |
|
||||
| `RATE_LIMITED` | 429 | Resend cooldown not yet elapsed. |
|
||||
| `CODE_EXPIRED` | 410 | 10-minute window passed. |
|
||||
| `CODE_INVALID` | 401 | Wrong code, attempts remain on this `requestId`. |
|
||||
| `REQUEST_NOT_FOUND` | 404 | `requestId` unknown, exhausted (5 wrong attempts), or expired. |
|
||||
|
||||
Admin can toggle which login methods (Telegram/Email/Phone) are shown to shoppers — this is a client-only UI gate (Admin Settings, `LocalStorageService`-persisted), not a backend flag; all endpoints stay available regardless of the toggle state.
|
||||
|
||||
See `docs/superpowers/specs/2026-08-15-email-phone-login-design.md` for the full design. No client code exists yet — nothing to build against a 404.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user