sdarbinyan
061d303805
users.vitanova.network:456 flatly 403s the CORS preflight for https://admin.gorbushka.market (no CORS headers at all) while https://novo.market gets a full grant (204, explicit Access-Control-Allow-Origin + wildcard Allow-Headers). This is a server-side origin allowlist, not something the frontend can route around - confirmed live via curl OPTIONS against both origins. This makes item 1 (X-Marketplace-Domain CORS confirmation) load-bearing for the gorbushka admin login fix in progress on the marketplaces repo: the frontend fix is ready but cannot work until this origin is added.
4.3 KiB
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:
- Add the gorbushka origins to the allowlist on
users.vitanova.network:456. At minimum:https://admin.gorbushka.marketandhttps://gorbushka.market. Confirm if any other gorbushka-family origins need it too (subdomains,www., etc. — whatever the real deployment topology needs). - Confirm the allowlist entry for these origins includes
X-Marketplace-DomaininAccess-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). - 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.