Open chaoky opened 1 year ago
This should already be the case. Are you seeing something different?
On supabase the /graphql/v1/
endpoint goes through PostgREST RPC so those headers are still available. Thats also how the role management works
in a fresh supabase local instance
create table "public"."notifications" (
"id" bigint generated by default as identity not null
);
create function "public"."_test"("public"."notifications")
returns json
language sql as
$$
select current_setting('request.headers', true)::json
$$;
with this query
{
notificationsCollection {
edges {
node {
test
}
}
}
}
besides Authorization, all of the other headers seem static
{
"x-forwarded-port": "8000",
"x-real-ip": "172.21.0.11",
"host": "supabase_rest_dashboard:3000",
"x-forwarded-host": "supabase_kong_dashboard",
"content-type": "application/json",
"accept": "*/*",
"sec-fetch-mode": "cors",
"apikey": "...",
"accept-language": "*",
"x-forwarded-prefix": "/graphql/v1",
"x-forwarded-proto": "http",
"x-forwarded-path": "/graphql/v1",
"user-agent": "undici",
"authorization": "Bearer ...",
"content-length": "150",
"accept-encoding": "gzip, deflate",
"x-forwarded-for": "172.21.0.11",
"connection": "keep-alive",
"content-profile": "graphql_public"
}
Reproduced by adding a customer header "Fooooo"
via GraphiQL and returning the response
@steve-chavez is there a way to forward custom headers so they're visible in he db or are they stripped for security?
Hm, no header is stripped. All headers (including custom) are passed.
Can you guys try with a plain curl
call? Not sure how that UI works for sending headers.
I tried with curl with the same result. If PostgREST is not stripping custom headers then it could be some other proxy or gateway along the route.
@imor Hm, how about trying with a header like Prefer: return=representation
? This is one that PostgREST needs and should pass unmodified by any proxy.
Also can you share the curl snippet?
besides Authorization, all of the other headers seem static "accept-language": "*",
Also, I do see the accept-language
in the request.headers output ^.
I sent the request using GraphiQL and then from the browser dev tools copied it as a curl command using the "Copy as cURL" context menu option. Here's the command line (edited to omit jwt):
curl "https://api.supabase.io/platform/projects/wcteuwpjlocwxcjvgtkp/api/graphql" -H "authority: api.supabase.io" -H "accept: application/json, multipart/mixed" -H "accept-language: en-US,en;q=0.8" -H "authorization: Bearer <omitted>" -H "content-type: application/json" -H "origin: https://supabase.com" -H "prefer: return=representation" -H "referer: https://supabase.com/" -H "sec-ch-ua: \"Not/A)Brand\";v=\"99\", \"Brave\";v=\"115\", \"Chromium\";v=\"115\"" -H "sec-ch-ua-mobile: ?0" -H "sec-ch-ua-platform: \"Windows\"" -H "sec-fetch-dest: empty" -H "sec-fetch-mode: cors" -H "sec-fetch-site: cross-site" -H "sec-gpc: 1" -H "user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/115.0.0.0 Safari/537.36" -H "x-graphql-authorization: Bearer <omitted>" --data-raw "{\"query\":\"{ usersCollection { edges { node { test1 } } }}\"}"
And these are the headers I get back (formatted for readability):
{
"baggage": "sentry-environment=production,sentry-release=d5bbed201eb20cc0a1af86619f58cea24cee017d,sentry-public_key=d5e18af8274946988586aab9276cd108,sentry-trace_id=cf9372e30f4e4002b4eb9d6b8bbb3185,sentry-sample_rate=0.002",
"cf-ipcountry": "FR",
"cf-visitor": "{\"scheme\":\"https\"}",
"x-forwarded-port": "443",
"x-real-ip": "172.71.134.144",
"host": "localhost:3000",
"x-consumer-username": "service_role-key",
"cf-worker": "supabase.co",
"x-forwarded-host": "wcteuwpjlocwxcjvgtkp.supabase.co",
"sentry-trace": "cf9372e30f4e4002b4eb9d6b8bbb3185-b06142310af2d6b7-0",
"accept": "*/*",
"cf-ray": "7f0d03d771d3f18c-CDG",
"x-forwarded-prefix": "/graphql/v1",
"x-consumer-id": "777f6130-904b-5657-ba5f-1e56d7f28356",
"x-credential-identifier": "764f2ba4-c7e4-5675-8f8d-83fa1c813e09",
"x-forwarded-proto": "https",
"x-forwarded-path": "/graphql/v1",
"user-agent": "node-fetch/1.0 (+https://github.com/bitinn/node-fetch)",
"authorization": "Bearer <omitted>",
"content-length": "84",
"cf-ew-via": "15",
"accept-encoding": "gzip",
"x-forwarded-for": "167.88.159.69, 172.71.134.144",
"connection": "keep-alive",
"cf-connecting-ip": "167.88.159.69",
"content-profile": "graphql_public",
"cdn-loop": "cloudflare; subreqs=1"
}
The prefer: return=representation
header is missing.
It's really strange because we have had many discussions around using request.headers
for custom logic and it has been working normally. For example, see https://github.com/orgs/supabase/discussions/4419#discussioncomment-4321279
So there must be something up with the graphql endpoint, maybe Kong is stripping the headers.
PostgREST on latest version using Supabase-js passes thru custom headers.
See the header custom:"hi there"
Summary
set the "request.headers" setting to the graphql request headers
Rationale
this functionality is already offered by supabase postgrest and it's very useful for i18n
Examples
Alternatives
in hasura, the metadata is injected into computed fields as an argument