digital-identity-platform-docs
digital-identity-platform-docs / supabase/functions/bigquery-export-test
supabase/functions/bigquery-export-test
Fileoverview
BigQuery Export — connection test
Answers the one question the BigQuery settings tab cannot answer on its own: "has this client actually granted our service account access to their dataset yet?" The grant happens in the client's Google Cloud console, which we cannot see, so the only honest check is to go and try.
Cloudflare Architecture Context
| Attribute | Value |
|---|---|
| Classification | 🔵 BACKEND-ONLY |
| Position | App Backend (Container → BigQuery export tab) |
| Receives Public Traffic | No (authenticated users only) |
| Latency Sensitive | No |
| Safe to Retry | Yes (creates the destination table at most once) |
| Failure Behavior | Returns ok: false plus Google's own error text |
Endpoint
POST /bigquery-export-test
Auth
Required - JWT in Authorization header
Remarks
Why this is a function and not a direct call from the browser:
- The cron worker is authenticated with a shared secret that must never reach a browser, so the call has to be made server side.
- The test uses the platform's Google identity. Letting a browser name the project and dataset to probe would turn our service account into an open scanner for whatever it can reach. So the request names a destination row id, this function proves the caller may touch that container, and the worker re-reads the address from the database. The address in the request body is never trusted, because there isn't one.
The permission check runs as the CALLER (their JWT), so the RLS policy on bigquery_export_destinations is what decides: a member who is not an admin of the container's client sees no row and gets a 403.