docs: add admin method toggle + error handling to email/phone login spec
Some checks failed
Architecture Governance / architecture (push) Has been cancelled

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
sdarbinyan
2026-08-15 18:52:52 +04:00
parent aedc05110c
commit e818dc6fc0
2 changed files with 35 additions and 2 deletions

View File

@@ -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.