fix(stack): echo requested headers on CORS preflight#5815
Open
martijnwalraven wants to merge 1 commit into
Open
fix(stack): echo requested headers on CORS preflight#5815martijnwalraven wants to merge 1 commit into
martijnwalraven wants to merge 1 commit into
Conversation
The proxy short-circuits every OPTIONS with 204 and a static allow-headers list, so the backing services' own CORS handling is never consulted — and the static list predates what browser clients send today (supabase-js 2.x adds x-supabase-api-version, PostgREST reads Prefer and the profile headers), so credentialless browser calls through the proxy failed CORS preflight (net::ERR_FAILED, observed at a real web e2e). This is the same skew class auth fixed for itself in supabase/auth#1612 after supabase/auth#1589 — a fix this proxy's short-circuit masks. Preflights now echo the requested headers, which is exactly what the classic CLI's proxy does: its kong.yml ships the bare cors plugin, and Kong's handler reflects Access-Control-Request-Headers when no header list is configured. Echo over a wildcard because `*` is literal (not a wildcard) for credentialed requests. The echo is preflight-only; the static list stays for preflights naming no headers and for non-preflight responses. Regression tests cover the echo and its preflight-only boundary. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The API proxy short-circuits every
OPTIONSwith 204 and a staticaccess-control-allow-headerslist, so the backing services' own CORS handling is never consulted. The static list predates headers today's browser clients send — supabase-js 2.x addsx-supabase-api-version(the same skew class as supabase/auth#1589, fixed service-side in supabase/auth#1612, but the proxy's short-circuit masks that fix), and postgrest-js writes sendPrefer. Result: credentialless browser calls through the proxy fail CORS preflight (net::ERR_FAILED; hit in a real web e2e suite).Fix
Preflights echo the request's
Access-Control-Request-Headers. That is also what the classic CLI's proxy already does: itskong.ymlships the barecorsplugin, and Kong's handler reflectsAccess-Control-Request-Headerswhen no header list is configured — so this restores parity with the Go CLI's behavior rather than inventing policy. Echo over a wildcard because*is literal (not a wildcard) for credentialed requests. The echo is preflight-only; the static list stays for preflights naming no headers and for non-OPTIONSresponses.Tests
🤖 Generated with Claude Code