fix: revert explicit apikey header (caused Kong duplicate-apikey 401)
api-ci-deploy / test-build-deploy (push) Has been cancelled
api-ci-deploy / test-build-deploy (push) Has been cancelled
The previous commit added apikey to _create_base_client headers, but supabase-py already sets apikey from the key arg → two apikey headers → Kong rejected every as-user call with 401 'Duplicate API key found' (exam API 502'd on auth). Revert to Authorization-only; fix the two header unit tests to assert the real contract (apikey via the key arg; options.headers carries only the user Authorization). Co-Authored-By: Claude Opus 4.8 <[email protected]>
This commit is contained in:
co-authored by
Claude Opus 4.8
parent
f3da9f3b59
commit
93972a62f7
@@ -24,12 +24,11 @@ def _create_base_client(url: str, key: str, access_token: Optional[str] = None,
|
||||
# Otherwise fall back to the API key
|
||||
auth_header = f"Bearer {access_token}" if access_token else f"Bearer {key}"
|
||||
|
||||
# apikey is required by the Supabase gateway (Kong) on every request and is independent of
|
||||
# Authorization: for a per-user client apikey stays the anon key while Authorization carries
|
||||
# the user's JWT (so RLS sees auth.uid()). Set it explicitly rather than relying on
|
||||
# create_client's internal default-header behaviour, which our options.headers override.
|
||||
# Only override Authorization here. apikey is supplied to create_client via the `key` arg and
|
||||
# set by supabase-py itself; setting it again here sends a DUPLICATE apikey header that the
|
||||
# Supabase gateway (Kong) rejects with 401 "Duplicate API key found". For a per-user client
|
||||
# apikey stays the anon key (from `key`) while this Authorization carries the user JWT.
|
||||
headers = {
|
||||
"apikey": key,
|
||||
"Authorization": auth_header,
|
||||
}
|
||||
if options:
|
||||
|
||||
Reference in New Issue
Block a user