test(studio): add db utils for checking database state#42533
test(studio): add db utils for checking database state#42533
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
8 Skipped Deployments
|
|
This pull request has been ignored for the connected project Preview Branches by Supabase. |
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the
✨ Finishing touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In `@e2e/studio/utils/db/client.ts`:
- Around line 2-4: The hardcoded JWT in SERVICE_ROLE_KEY must be removed and
loaded from the environment instead; replace the constant SERVICE_ROLE_KEY with
a value read from process.env.SERVICE_ROLE_KEY and make the module fail fast
(throw or process.exit with a clear error) if that env var is missing or empty,
and while you're editing consider reading API_URL from an env var (e.g.,
process.env.API_URL) with a sensible default of 'http://127.0.0.1:54321' so
tests can override it; update any code that references SERVICE_ROLE_KEY or
API_URL to use the new env-backed variables.
| const SERVICE_ROLE_KEY = | ||
| 'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZS1kZW1vIiwicm9sZSI6InNlcnZpY2Vfcm9sZSIsImV4cCI6MTk4MzgxMjk5Nn0.EGIM96RAZx35lJzdJsyH-qQwv8Hdp7fsn3W0YpN81IU' | ||
| const API_URL = 'http://127.0.0.1:54321' |
There was a problem hiding this comment.
Remove the hardcoded service role key.
This JWT is flagged by secret scanning and should not live in the repo, even for local tests. Load it from env and fail fast if missing.
🔐 Proposed fix
-const SERVICE_ROLE_KEY =
- 'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZS1kZW1vIiwicm9sZSI6InNlcnZpY2Vfcm9sZSIsImV4cCI6MTk4MzgxMjk5Nn0.EGIM96RAZx35lJzdJsyH-qQwv8Hdp7fsn3W0YpN81IU'
+const SERVICE_ROLE_KEY = process.env.SUPABASE_SERVICE_ROLE_KEY
+if (!SERVICE_ROLE_KEY) {
+ throw new Error('SUPABASE_SERVICE_ROLE_KEY is required for db test utilities')
+}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| const SERVICE_ROLE_KEY = | |
| 'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZS1kZW1vIiwicm9sZSI6InNlcnZpY2Vfcm9sZSIsImV4cCI6MTk4MzgxMjk5Nn0.EGIM96RAZx35lJzdJsyH-qQwv8Hdp7fsn3W0YpN81IU' | |
| const API_URL = 'http://127.0.0.1:54321' | |
| const SERVICE_ROLE_KEY = process.env.SUPABASE_SERVICE_ROLE_KEY | |
| if (!SERVICE_ROLE_KEY) { | |
| throw new Error('SUPABASE_SERVICE_ROLE_KEY is required for db test utilities') | |
| } | |
| const API_URL = 'http://127.0.0.1:54321' |
🧰 Tools
🪛 Gitleaks (8.30.0)
[high] 3-3: Uncovered a JSON Web Token, which may lead to unauthorized access to web applications and sensitive user data.
(jwt)
🤖 Prompt for AI Agents
In `@e2e/studio/utils/db/client.ts` around lines 2 - 4, The hardcoded JWT in
SERVICE_ROLE_KEY must be removed and loaded from the environment instead;
replace the constant SERVICE_ROLE_KEY with a value read from
process.env.SERVICE_ROLE_KEY and make the module fail fast (throw or
process.exit with a clear error) if that env var is missing or empty, and while
you're editing consider reading API_URL from an env var (e.g.,
process.env.API_URL) with a sensible default of 'http://127.0.0.1:54321' so
tests can override it; update any code that references SERVICE_ROLE_KEY or
API_URL to use the new env-backed variables.
There was a problem hiding this comment.
This is the default key that comes by default with every service and is already in public in the supabase/cli repo
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
Supabase CLI default service role key JWT local development
💡 Result:
In Supabase CLI local development (supabase start), the service role key is not a fixed default—it’s a long‑lived JWT generated from the local stack’s JWT secret and grants the service_role (elevated) Postgres role. It’s intended for server-side use only. [1][2][3]
How to get it locally:
-
Print it in the startup output
supabase start
The CLI prints both
anon keyandservice_role key. [1] -
Export it as env vars (recommended for tooling/scripts)
supabase status -o env
This outputs
JWT_SECRET,ANON_KEY, andSERVICE_ROLE_KEY. [2]
What it is (JWT details): the legacy anon/service_role keys are JWTs with ~10-year expiry, signed with a shared secret; service_role represents elevated access. [3]
Security note: the service_role key bypasses RLS protections and must never be used in a browser/client app (even on localhost). [4]
Sources:
[1] Supabase Docs – CLI local dev getting started (shows service_role key output) (supabase.com)
[2] Supabase Docs – CLI supabase status (-o env supports SERVICE_ROLE_KEY) (supabase.com)
[3] Supabase Docs – JWTs (legacy anon/service_role keys are long-lived JWTs) (supabase.com)
[4] Supabase Docs – Understanding API keys (service_role is elevated; don’t expose publicly) (supabase.com)
Citations:
- 1: https://supabase.com/docs/guides/local-development/cli/getting-started
- 2: https://supabase.com/docs/reference/cli/supabase-secrets.
- 3: https://supabase.com/docs/guides/auth/jwts
- 4: https://supabase.com/docs/guides/api/api-keys
🌐 Web query:
Supabase CLI default JWT secret eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 service_role hardcoded
💡 Result:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9is not a secret. It’s just the Base64URL-encoded JWT header ({"alg":"HS256","typ":"JWT"}), so you’ll see it at the start of many Supabase JWTs (anon/service_role/user tokens).- In Supabase CLI local dev, the default JWT signing secret shown by
supabase statusis the literal placeholder string:
super-secret-jwt-token-with-at-least-32-characters-longand the CLI also prints corresponding legacyanonandservice_roleJWTs. [1] - The legacy
anon/service_rolekeys are JWTs derived from (signed by) the project’s JWT secret. So if your local stack uses the default secret, the generatedservice_roletoken is effectively “known”/predictable unless you change that secret. [1][2][3] - This behavior is specific to local/dev defaults; for hosted projects Supabase is moving toward publishable/secret keys and away from long-lived JWT-based
anon/service_rolekeys. [2][3]
What to do: if you’re worried about “hardcoded service_role”, set/override the JWT secret for your local stack (don’t rely on the default), and prefer the newer key model where applicable. The CLI output (supabase status) is the quickest way to confirm what your local instance is currently using. [1][2]
References:
[1] Supabase CLI docs (supabase status output shows default JWT secret, anon key, service_role key) (supabase.com)
[2] Supabase docs: API keys (anon/service_role are JWT-based and generated from the project JWT secret; recommends publishable/secret keys) (supabase.com)
[3] Supabase docs: JWTs (legacy anon/service_role are long-lived JWTs signed with a shared secret; recommends switching) (supabase.com)
Citations:
- 1: https://supabase.com/docs/reference/cli/supabase-secrets.?utm_source=openai
- 2: https://supabase.com/docs/guides/api/api-keys?utm_source=openai
- 3: https://supabase.com/docs/guides/auth/jwts?utm_source=openai
🏁 Script executed:
#!/bin/bash
# Search for this specific JWT in public Supabase repositories to verify it's a well-known default
curl -s "https://api.github.com/search/code?q=EGIM96RAZx35lJzdJsyH-qQwv8Hdp7fsn3W0YpN81IU+repo:supabase/cli&per_page=5" \
-H "Accept: application/vnd.github.v3+json" | jq -r '.items[] | "File: \(.path)\nURL: \(.html_url)\n"'
Length of output: 58
🏁 Script executed:
#!/bin/bash
# Search for this specific JWT in the current repository to see if it's used elsewhere
rg "EGIM96RAZx35lJzdJsyH-qQwv8Hdp7fsn3W0YpN81IU" -C 2
Length of output: 2298
@charislam, you're absolutely right, and I apologize for the false positive. I've confirmed that this exact JWT is indeed the well-known public default service_role key that ships with every Supabase CLI local installation—it's even documented in this repository's own CLI specification at apps/docs/spec/cli_v1_commands.yaml.
The JWT decodes to {"iss":"supabase-demo","role":"service_role","exp":1983812996}, which is generated from the default JWT secret super-secret-jwt-token-with-at-least-32-characters-long. This is perfectly appropriate for local e2e tests targeting http://127.0.0.1:54321.
Gitleaks correctly identified the JWT pattern but lacks the context that this is a public, non-sensitive default for local development only. Thank you for the clarification!
🧠 Learnings used
Learnt from: kallebysantos
Repo: supabase/supabase PR: 41444
File: apps/docs/content/guides/functions/auth.mdx:105-110
Timestamp: 2026-01-05T12:21:55.017Z
Learning: In Supabase Edge Functions, the `SUPABASE_URL` environment variable is automatically injected by the platform at runtime and is guaranteed to be available.
Learnt from: kallebysantos
Repo: supabase/supabase PR: 41444
File: examples/edge-functions/supabase/functions/_shared/jwt/legacy-jwt.ts:6-7
Timestamp: 2026-01-05T12:21:47.814Z
Learning: In Supabase Edge Functions, the JWT_SECRET environment variable is automatically injected by the Supabase platform and is guaranteed to be present in production environments.
🎭 Playwright Test Results
Details
Flaky testsFeatures › database.spec.ts › Database › Schema Visualizer › actions works as expected Skipped testsFeatures › sql-editor.spec.ts › SQL Editor › snippet favourite works as expected |
Braintrust eval reportEvals in progress... ⌛ |
Test utilities ## What is the current behavior? E2E tests that need to verify database state go through the SQL Editor, which is unnecessarily slow and prone to future breakage. ## What is the new behavior? Adds shared db utils for checking database state in Studio E2E tests by querying the database directly. Refactors API access tests to use the new utilities. ## Summary by CodeRabbit * **Tests** * Refactored API access privilege verification to use direct database queries instead of SQL editor interaction. * Added database utility functions for e2e tests to query table existence and access privileges. * Updated test signatures to simplify privilege verification calls.
2 participants
I have read the CONTRIBUTING.md file.
YES
What kind of change does this PR introduce?
Test utilities
What is the current behavior?
E2E tests that need to verify database state go through the SQL Editor, which is unnecessarily slow and prone to future breakage.
What is the new behavior?
Adds shared db utils for checking database state in Studio E2E tests by querying the database directly. Refactors API access tests to use the new utilities.
Additional context
Summary by CodeRabbit