digital-identity-platform-docs
digital-identity-platform-docs / supabase/functions/dashboards-list
supabase/functions/dashboards-list
Fileoverview
Dashboards List Edge Function
Returns the reports available to a client. DIP does not own this list: the dashboard registry lives in the reporting product's Cloudflare D1, and this function reads it live so there is exactly one source of truth and no sync job to drift.
Cloudflare Architecture Context
| Attribute | Value |
|---|---|
| Classification | 🔵 BACKEND-ONLY |
| Position | App Backend (Dashboards tab) |
| Receives Public Traffic | No (authenticated users only) |
| Latency Sensitive | No |
| Safe to Retry | Yes (read-only) |
| Failure Behavior | Returns an explicit unavailable flag, never a partial list |
Endpoint
POST /dashboards-list
Auth
Required - JWT in Authorization header
Remarks
Why this is a function and not a table read:
- The reporting worker is authenticated with a shared secret. That secret must never reach a browser, so the call has to be made server side.
- It answers "what does tenant X have" without a per-user check, so the caller has to be the one that decides the requester belongs to tenant X. That decision is made here, against DIP's own permissions.
Two checks happen before the outbound call, and both matter:
dashboards.viewfor this client, via the same has_permission() the RLS policies use. Runs as the CALLER (their JWT), not the service role, so a member who was never granted dashboards gets nothing.- The tenant slug is read from the client row server side. It is never taken from the request body - a caller who could name their own tenant could read another organisation's dashboard list.