# vitanovaPackages — backend team TODO

Everything here needs a decision or confirmation from whoever owns the central Auth API / Payment API. Nothing in this list can be resolved from the frontend side alone. Hand this file to them directly.

## 1. Confirm `X-Marketplace-Domain` CORS support (blocking) — NOW LOAD-BEARING, ORIGIN ALLOWLIST CONFIRMED MISSING
As of 2026-08-23, `@marketplaces/auth` and `@marketplaces/payment` send the marketplace domain as a request header (`X-Marketplace-Domain`) exclusively. The previous query-parameter/body fallback (`contextTransport: 'parameter'`, kept for backends that hadn't allowed the header in CORS preflight) has been **removed**, not just de-defaulted.

**Backend must confirm**: both the Auth API and the Payment API allow `X-Marketplace-Domain` in CORS preflight (`Access-Control-Allow-Headers`), and reject requests with an unknown/disabled domain in that header. See `docs/BACKEND-CONTRACT.md` for the full contract.

If either service can't allow that header for some environment (legacy proxy, CDN stripping custom headers, etc.), say so before this ships — the frontend has no fallback for it anymore.

**2026-08-24 finding — this is now actively blocking the gorbushka admin login fix:**

`users.vitanova.network:456` (the auth host) rejects the CORS preflight
outright for gorbushka origins, before it even reaches app-level CORS
logic:

```
OPTIONS /users/sessions  Origin: https://admin.gorbushka.market
  -> 403 Forbidden, no CORS headers at all

OPTIONS /users/sessions  Origin: https://novo.market
  -> 204 No Content
     Access-Control-Allow-Origin: https://novo.market
     Access-Control-Allow-Headers: *
     Access-Control-Allow-Methods: GET,POST,PUT,DELETE,OPTIONS
     Access-Control-Allow-Credentials: true
```

This is a server-side **origin allowlist** — `novo.market` is on it,
`gorbushka.market`/`admin.gorbushka.market` is not. The frontend fix
(pointing `AUTH_API_URL` at this host instead of the wrong tenant
content origin) is ready but cannot work for gorbushka until this
lands — no frontend change can route around a 403 the browser gets
before the request is even sent.

**Request:**
1. Add the gorbushka origins to the allowlist on `users.vitanova.network:456`.
   At minimum: `https://admin.gorbushka.market` and `https://gorbushka.market`.
   Confirm if any other gorbushka-family origins need it too (subdomains,
   `www.`, etc. — whatever the real deployment topology needs).
2. Confirm the allowlist entry for these origins includes
   `X-Marketplace-Domain` in `Access-Control-Allow-Headers` (novo.market's
   grant above uses a wildcard `*`, which already covers it there — confirm
   gorbushka's entry does too, don't assume the wildcard is uniform across
   all allowlisted origins).
3. Same allowlist question applies to `qr.vitanova.network` (payment) —
   not yet checked for gorbushka origins, worth confirming in the same pass.

Until this lands, no frontend change makes browser login work for gorbushka.

## 2. `@marketplaces/payment` version discipline
`@marketplaces/payment` changed the same way as auth (dropped param-transport) but was never version-bumped past 0.2.0, even though it's a behavior-breaking change for anyone integrating against it. Not a backend question exactly, but flagging since payment's release process seems to have skipped a changeset for this — worth a process check.

## 3. Rate-limiting on admin credentials login
`AdminAuthService.loginWithCredentials()` (new in `@marketplaces/auth` 0.3.0) expects `429` with a `Retry-After` header (seconds) for rate-limited attempts, and maps that to a `rate_limited` failure code with `retryAfterSeconds`. Confirm the Auth API actually returns `Retry-After` on 429 for `POST {credentialsPath}` — if it uses a different mechanism (custom header, response body field), the frontend's parsing needs to match.

## 4. Ed25519 admin auth — still just future work
No change requested here, just a status check: `packages/auth/src/ed25519/` (challenge/response admin auth) has never had a backend. As of 2026-08-23 it's also no longer exported from the package's public API (dead code in the bundle otherwise). If/when that backend gets built, this needs re-exporting and a real integration pass — flag when that's on the roadmap so the frontend side can be scheduled.