docs(backend): log live Telegram CORS incident, admin credentials wiring
Some checks failed
Architecture Governance / architecture (push) Failing after 1m28s
Deploy Frontend / deploy (push) Successful in 2m6s

users.vitanova.network:456/users/sessions 403s every tested origin with
no CORS headers - the only working admin auth path is broken in prod.
Logged in §1.2 and the change log with evidence, plus the frontend's new
POST /api/identity/v1/session wiring (safe to leave in place pre-backend:
every failure surfaces one generic message).
This commit is contained in:
sdarbinyan
2026-08-27 04:05:37 +04:00
parent 80c9978e03
commit c990c10307
2 changed files with 5 additions and 1 deletions

View File

@@ -48,7 +48,9 @@ Auth lives in `@marketplaces/auth` (published from vitanovaPackages; see `../PAC
**The critical gap:** the session API has no concept of "admin." The frontend only chooses where to *store* the result. **Every admin endpoint must independently verify authorization server-side** — client-side guards are UI convenience, never security. Admin requests carry `AdminWebSessionID: <sessionId>` (and `Authorization: Bearer <token>` once admin JWTs exist) on paths containing `/admin/`, `/backoffice/`, `/builder/`, `/media/`.
**Admin credential (login/password) auth — required, not yet built.** `admin.gorbushka.market` can authenticate via Telegram today; login/password is not implemented, so the frontend must not validate or embed admin credentials, and the Ed25519 `/admin-login` page is not production-ready (its challenge/verify endpoints don't exist). Tenant identity comes only from nginx's trusted `X-Storefront-Host` — never from the login body.
**🔴 LIVE INCIDENT — Telegram QR/session CORS blocks all admin and customer login (found 2026-08-26).** `POST https://users.vitanova.network:456/users/sessions` returns `403` for every origin tested — `https://gorbushka.market`, `https://admin.gorbushka.market`, `https://store1.gorbushka.market` — both on the actual request and on the `OPTIONS` preflight, with zero `Access-Control-Allow-*` headers in the response. This is the endpoint marked "live" above; it is not currently usable from any storefront or admin origin, so Telegram login (the *only* working admin auth method) is fully broken in production right now. Needs the CORS allowlist on that service updated to include the storefront/admin origins — same root cause already flagged in the `vitanovaPackages` PR `fix/auth-payment-origin-decouple`.
**Admin credential (login/password) auth — required, not yet built.** `admin.gorbushka.market` can authenticate via Telegram today (see incident above — currently broken); login/password is not implemented, so the frontend must not validate or embed admin credentials, and the Ed25519 `/admin-login` page is not production-ready (its challenge/verify endpoints don't exist). Tenant identity comes only from nginx's trusted `X-Storefront-Host` — never from the login body. **The frontend now calls this contract** (2026-08-26, admin login dialog, "Войти по логину и паролю" toggle) — every request 404s until the endpoint exists; the UI treats any failure uniformly as "something went wrong, try another way to sign in" and never surfaces the raw backend response, so this is safe to leave wired while the endpoint doesn't exist yet.
```http
POST /api/identity/v1/session { login, password }
@@ -434,6 +436,7 @@ Write: `POST /companies/{id}/projects`, `/projects/{id}/stores`, `/stores/{id}/p
Append here whenever a section changes. Newest first.
- **2026-08-26** — Frontend now wires `POST /api/identity/v1/session` (§1.2 admin credential contract) from the admin login dialog, behind a "Войти по логину и паролю" toggle; every call 404s until the backend endpoint exists, surfaced to the user as one generic message, never the raw error. **Also found and logged a live incident** in the same section: the Telegram QR/session endpoint (`users.vitanova.network:456/users/sessions`) 403s every tested origin with no CORS headers at all — Telegram login, currently the only working admin auth path, is fully broken in production. Not a frontend fix; needs the backend CORS allowlist updated.
- **2026-08-22** — Added `published: boolean` to the bootstrap response contract (§1.1): frontend now renders a built-in generic placeholder (all feature flags on) for any marketplace with no published revision, decided from this one field rather than HTTP status. See [Brand-bootstrap design](../superpowers/specs/2026-08-22-frontend-default-bootstrap-design.md).
- **2026-08-22** — Consolidated the entire `docs/backend/` set into this one file per the single-doc rule; folded in the admin credential (login/password) auth handoff (§1.2). No contract content changed; the former per-phase files are removed.
- **2026-08-21** — Harvest additions (`FH-*`) folded in across §4§13, from the parallel-platform review ([ADR-0006](../context/adrs/ADR-0006-harvest-mechanisms-from-the-parallel-platform.md)): atomic reservation, inventory journal, idempotency constraints, session model, origin allowlist, secret envelope, order public token, revision immutability/clone/preview, tenant resolution hardening, server-side content validation, digital code pools, order-manager contour, provider-agnostic identity + VK/Yandex + Telegram migration, host hardening.

View File

@@ -12,3 +12,4 @@
{"id":"PV-20260818T104400Z-d9e2","subject":"partner-api-credentials","predicate":"are-scoped-by","object":"a single node whose subtree defines authority; we hold only the partner-generated public key, rotation runs on a bounded overlap window and revocation is immediate and irreversible","src":["docs/backend/PARTNER-PROVISIONING-API-CONTRACT.md","docs/backend/TRACK-S-SECURITY-RBAC-CONTRACT.md"],"status":"active","kind":"decision","updated_at":"2026-08-18T10:44:00Z","confidence":"high","tags":["security","credentials","partner"]}
{"id":"PV-20260818T104500Z-a6f7","subject":"checkout-payment-methods","predicate":"already-support","object":"both qr and card end to end in src/app/pages/cart/cart.component.ts (separate create paths and separate status pollers); card is not an outstanding gap","src":["src/app/pages/cart/cart.component.ts","src/app/services/api.service.ts"],"status":"active","kind":"implemented","updated_at":"2026-08-18T10:45:00Z","confidence":"high","tags":["payments","frontend"]}
{"id":"PV-20260820T095500Z-b17e","subject":"tenant-api-routing","predicate":"is-decided-to-use","object":"one runtime-derived API origin per base domain; example.com and store1.example.com both map to api.example.com for bootstrap, auth, legacy, and versioned endpoints","src":["docs/context/adrs/ADR-0005-share-api-host-across-storefront-subdomains.md","src/app/core/config/api-config.service.ts"],"status":"active","kind":"decision","updated_at":"2026-08-20T16:00:00Z","confidence":"high","tags":["architecture","multi-tenant","api","routing","dns"]}
{"id":"AUTH-20260827T000509Z-69a3","subject":"admin login/password form","predicate":"calls","object":"POST /api/identity/v1/session (not yet live; generic error on any failure)","src":["src/app/components/telegram-login/telegram-login.component.ts","docs/backend/BACKEND-INTEGRATION.md"],"status":"active","kind":"implemented","updated_at":"2026-08-27T00:05:09.874Z","confidence":"high"}