mirror of
https://github.com/supabase/supabase.git
synced 2026-10-07 18:35:07 +03:00
Matt Johnston
34c2092a62
On a deployment where `NIMBUS_PROD_PROJECTS_URL` is supplied to the build but not to the function runtime, testing an edge function fails with a 400, "Provided URL is not a valid Supabase edge function URL", while the CSP on the same page already allows the projects domain. The two readers run at different times. `csp.ts` is imported by `next.config.ts` and evaluated during the build, so it sees the value. `lib/api/edgeFunctions.ts` is evaluated inside the API route at request time, where the variable is absent, so `isValidEdgeFunctionURL` falls through to the default `<ref>.supabase.(co|red)` check and rejects every projects URL. Declaring the variables under `env` pins both readers to the same build-time value: `getNextConfigEnv` turns each key into a `process.env.<key>` define, and `getDefineEnv` applies those to every compilation rather than only the client, so the pages API route gets the substitution too. This is a no-op where the variables are unset — `getNextConfigEnv` skips null values, leaving `process.env.*` as an ordinary runtime lookup for self-hosted and OSS builds. The values are wildcard domains that already appear in the public CSP header, so inlining them into the client bundle exposes nothing new.