- Shipped
- October 18, 2026 at 6:45 AM UTC
- Author
- Kamo
- Commit
- 6a689d9
The Kamo OAuth server's public endpoints, relayed to SecurityService (O1, O6, O7) over cluster DNS at SECURITY_SERVICE_URL (default kamowssecurity-service, as app/api/recover does): - GET /oauth/authorize forwards only the seven OAuth parameters and answers a relative 303: /?oauth_request=<id> for a valid request, the client's registered https: redirect for a redirect error, /oauth/error otherwise (an unknown client or unregistered redirect URI is shown, never redirected to). - POST /oauth/token and /oauth/revoke forward the body byte for byte with Authorization and Content-Type only (plus the caller's address for SecurityService's limit), relay WWW-Authenticate, always no-store; a fault, or any status that is not the endpoint's own (200/400/401/429/503), is 503 temporarily_unavailable — never invalid_grant. - **************** in OAuthShell (bundled Kamo logo, Privacy and Terms on www.kamocrm.com, nothing from another origin). app/lib/***Cookie.ts is the one copy of the clear-then-set *** block that /api/login, /api/session/select and /api/login/mfa each carried. The three copies were attribute-for-attribute identical, so nothing is parameterised; the helper takes the Host header the routes read. Finding, preserved on purpose: Next's cookie jar is keyed by name, so only the last set() reaches the wire — the three clears never did. tests/***-cookie pins the exact Set-Cookie headers against the old inline block, for each route end to end. npm test = node --experimental-strip-types --test tests/*.test.mjs (Node 22 takes no directory argument, and planCheckout.test.mjs imports a .ts).