[nicknisi]

Description

API requests follow redirects today (fetch's default redirect: 'follow'). authenticateWithCode and authenticateWithRefreshToken send client_secret in the request body, so if the API origin (or a configured apiHostname) ever answers with a 307/308, the SDK re-posts the body, secret included, to wherever the redirect points. The Authorization header is dropped cross-origin; the body is not. GET responses from the redirect target are also accepted as if they came from the API. Reported against authkit-nextjs in workos/authkit-nextjs#510.

Changes

• FetchHttpClient sets redirect: 'manual', so redirects are never followed. I used 'manual' rather than 'error' because Cloudflare workerd rejects 'error' ("Invalid redirect value..."), and 'error' rejects with a TypeError, which shouldRetryRequest retries.
• A 3xx (or a browser opaqueredirect) throws an HttpClientError that names the status and Location, so callers get a GenericServerException like WorkOS API responded with a redirect (301 to https://...). Redirects are not followed; check the apiHostname, port and https options. Without this, the HTML redirect body would be parsed as JSON and fail with a confusing ParseError. 3xx isn't in RETRY_STATUS_CODES, so it fails right away without retrying.
• The base WorkOS class (used by createWorkOS) now passes options.fetchFn to FetchHttpClient. It silently ignored it before.
• I removed WorkOSWorker.createHttpClient (used under the workerd / edge-light conditions). It was a copy of the base method minus timeout, and it also ignored fetchFn. The worker build now uses the base method, so both fetchFn and timeout work on Edge and Workers.

Verification

• New real-HTTP test (native fetch and node-fetch): a 307 to /stolen isn't followed, the error names the redirect, and the request count stays at 1.

• New tests: a 301 surfaces as a GenericServerException naming the redirect; the worker client and createWorkOS use the provided fetchFn; the worker client respects timeout. All of them fail without the source changes.

• Repro against the built lib/ with a fake API returning a cross-origin 307 and a sink that records requests:

  Build	Before	After
  index.mjs (Node)	sink receives client_secret	nothing reaches the sink; redirect error in ~25ms
  index.worker.mjs on Node	sink receives client_secret	nothing reaches the sink
  index.worker.mjs on workerd (wrangler dev)	sink receives client_secret	nothing reaches the sink; custom fetchFn is called

• npm test, npm run typecheck, npm run prettier and npm run build (attw) pass.

Compatibility: no change against the real API, which doesn't redirect. Setups that point apiHostname at something that answers with a redirect now get an error that says so, instead of having the request silently re-sent. One real case: https: false against api.workos.com, which answers 301 to https. GET calls used to follow that; now they fail with the redirect error.

Note: the existing GH-1679 real-HTTP timeout tests (times out a successful JSON body..., surfaces a stalled error body...) flake locally on main as well. They use a 100ms timeout. The new redirect test uses the default timeout so it doesn't hit the same problem.

Documentation

Does this require changes to the WorkOS Docs? E.g. the API Reference or code snippets need updates.

[ ] Yes

[greptile-apps]

Confidence Score: 5/5

[High impact] The PR appears safe to merge; the previous connection-cleanup issue is fixed.

Summary

API requests now reject redirects instead of forwarding request bodies.

• WorkOS requests stop at redirects and return a clear error.
• Base and worker clients use the configured fetch function and timeout.

The previous finding is fixed. No new actionable issues were found. Tests were inspected but not run.

_{Reviews (3) · Last reviewed commit: "fix: release the connection on a redirec..." · Reviewed by Greptile}

[gjtorikian]

LGTM~