chore(supabase): drop legacy/dead Supabase env-var infra#764
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
6 Skipped Deployments
|
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (8)
💤 Files with no reviewable changes (6)
✅ Files skipped from review due to trivial changes (1)
🚧 Files skipped from review as they are similar to previous changes (1)
WalkthroughRemoves local Supabase ES256 JWT signing key configuration, CI generation step, related env vars and exported region/read-replica helpers; CIAM docs now describe an opaque server-issued session token model instead of minting JWTs. ChangesJWT signing key infrastructure removal
Possibly related PRs
Suggested labels
🎯 3 (Moderate) | ⏱️ ~20 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 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 |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 3725d4334e
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
supabase/schemas/grida_ciam.md (1)
88-97:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winDocumentation inconsistency between high-level flow and current implementation.
The "Authentication flow (high level)" section (lines 88-97) describes JWT minting and RLS reading JWT claims, but the "Current: opaque portal-session tokens" section (lines 102-114) explicitly states the system is "opaque URL-token based, not JWT based" and that "customer-session claims are not attached to DB requests today."
Update the high-level flow to accurately reflect the current opaque-token implementation, or clearly mark steps 3-4 as "Future" to avoid confusion.
As per coding guidelines: Keep schema documentation in supabase/schemas/ updated when making changes, treating it as best-effort documentation that should align with actual migrations.
📝 Suggested clarification
Option 1: Update the high-level flow to reflect current implementation:
-3. **Mint JWT** - - Backend mints a JWT containing a session identifier (`sid`). - - Client uses Supabase client `accessToken: async () => jwt`. +3. **Create portal session token** + - Backend generates an opaque URL-safe token and stores its hash. + - Token is returned to client for server-side redemption. -4. **RLS** - - DB helpers read `request.jwt.claims` and resolve: +4. **Identity resolution** (future: via RLS) + - Currently: server-side resolution using `service_role`. + - Future: DB helpers will read `request.jwt.claims` and resolve: - `customer_uid()` - `project_id()` - - Policies can reference these helpers to enforce row access. + - Policies will reference these helpers to enforce row access.Option 2: Keep the flow as aspirational but add a note:
### Authentication flow (high level) +> **Note**: Steps 3-4 describe the intended JWT-based model. Currently, the system uses opaque portal-session tokens (see "Session model & cryptography" below). + 1. **Create OTP challenge**Also applies to: 102-114
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@supabase/schemas/grida_ciam.md` around lines 88 - 97, Update the "Authentication flow (high level)" section in supabase/schemas/grida_ciam.md to match the actual opaque-token implementation: change steps "3. Mint JWT" and "4. RLS" to either (A) describe the current opaque portal-session token flow (portal issues opaque session token, client passes it as accessToken, DB requests do not carry customer-session JWT claims and helpers like customer_uid()/project_id() are not populated), or (B) mark steps 3–4 explicitly as "Future / aspirational" and add a short note referencing the existing "Current: opaque portal-session tokens" section so readers aren’t confused; ensure the documentation reflects which path (opaque vs JWT) is currently implemented.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Outside diff comments:
In `@supabase/schemas/grida_ciam.md`:
- Around line 88-97: Update the "Authentication flow (high level)" section in
supabase/schemas/grida_ciam.md to match the actual opaque-token implementation:
change steps "3. Mint JWT" and "4. RLS" to either (A) describe the current
opaque portal-session token flow (portal issues opaque session token, client
passes it as accessToken, DB requests do not carry customer-session JWT claims
and helpers like customer_uid()/project_id() are not populated), or (B) mark
steps 3–4 explicitly as "Future / aspirational" and add a short note referencing
the existing "Current: opaque portal-session tokens" section so readers aren’t
confused; ensure the documentation reflects which path (opaque vs JWT) is
currently implemented.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 5e3aeb85-5984-40bb-a62e-81538dbc4c29
📒 Files selected for processing (34)
.github/workflows/database-tests.ymleditor/.env.exampleeditor/env.tseditor/lib/ciam/server/jwt.tspackages/grida-agent-tools/tsdown.config.mtspackages/grida-ai-models/tsdown.config.mtspackages/grida-canvas-cg/tsdown.config.mtspackages/grida-canvas-color/tsdown.config.mtspackages/grida-canvas-hud/tsdown.config.mtspackages/grida-canvas-pixelgrid/tsdown.config.mtspackages/grida-canvas-ruler/tsdown.config.mtspackages/grida-canvas-sdk-render-figma/tsdown.config.mtspackages/grida-canvas-sequence/tsdown.config.mtspackages/grida-canvas-sync/tsdown.config.mtspackages/grida-canvas-transparency-grid/tsdown.config.mtspackages/grida-canvas-vn/tsdown.config.mtspackages/grida-cmath/tsdown.config.mtspackages/grida-fonts/tsdown.config.mtspackages/grida-format/tsdown.config.mtspackages/grida-history/tsdown.config.mtspackages/grida-keybinding/tsdown.config.mtspackages/grida-mixed-properties/tsdown.config.mtspackages/grida-number-input/tsdown.config.mtspackages/grida-reftest/tsdown.config.mtspackages/grida-svg-editor/tsdown.config.mtspackages/grida-svg/tsdown.config.mtspackages/grida-text-editor/tsdown.config.mtspackages/grida-tokens/tsdown.config.mtspackages/grida-tree-view/tsdown.config.mtspackages/react-p-queue/tsdown.config.mtssupabase/.gitignoresupabase/README.mdsupabase/config.tomlsupabase/schemas/grida_ciam.md
💤 Files with no reviewable changes (6)
- editor/lib/ciam/server/jwt.ts
- supabase/config.toml
- editor/.env.example
- .github/workflows/database-tests.yml
- supabase/README.md
- editor/env.ts
|
Addressed the |
Remove two pieces of unused Supabase env-var infrastructure that were
introduced but never wired into any live code path.
1. Read-replica routing (editor/env.ts)
- Delete the entire `Env.supabase` namespace: the 16
`NEXT_PUBLIC_SUPABASE_URL_RR_*` region constants,
`SUPABASE_READ_REPLICAL_URLS`, the fallback / AWS-region maps, the
`SupabaseRegion` type, and `rr()`. Nothing called `Env.supabase.rr()`;
the real clients read `process.env.NEXT_PUBLIC_SUPABASE_URL` directly.
- Delete the `Env.vercel` namespace (region table + `region()`), which
existed only to feed that routing.
- Supabase already does default region routing, so this layer was
unnecessary from the start.
2. CIAM JWT signing key (SUPABASE_SIGNING_KEY_JSON + ES256 signing keys)
- Delete editor/lib/ciam/server/jwt.ts (`signCustomerSessionToken` had
zero callers). The live CIAM portal flow uses opaque, sha256-hashed
session tokens resolved server-side via service_role, not signed JWTs.
- Remove `signing_keys_path` from supabase/config.toml (local Auth falls
back to the default symmetric jwt_secret) and drop the CI
`gen signing-key` step. Keep signing_keys.json gitignored so a
pre-existing local private JWK is never accidentally committed.
- Rewrite the README and grida_ciam.md sections (incl. the high-level
auth flow) to describe the actual opaque-token model; JWT/JWKS now
appears only as clearly-labeled, not-yet-implemented future work.
No behavior change for anything that runs. Verified:
turbo typecheck --filter=editor passes, `supabase stop && start` comes up
healthy without the signing key, and DB tests set identity via set_config
(not signed JWTs), so they are unaffected.
softmarshmallow
force-pushed
the
chore/drop-legacy-supabase-env-infra
branch
from
5ee8c97 to
7603818
Compare
1 participant
What & why
Removes two pieces of Supabase env-var infrastructure that were introduced but never wired into any live code path.
1. Read-replica routing (
editor/env.ts)Deletes the entire
Env.supabasenamespace — the 16NEXT_PUBLIC_SUPABASE_URL_RR_*region constants,SUPABASE_READ_REPLICAL_URLS, the fallback / AWS-region maps, theSupabaseRegiontype, and therr()resolver — plus theEnv.vercelnamespace (region table +region()), which existed solely to feed that routing.Nothing ever called
Env.supabase.rr(); the real clients (lib/supabase/{client,server,proxy}.ts) readprocess.env.NEXT_PUBLIC_SUPABASE_URLdirectly. Supabase already does default region routing, so the manual replica-selection layer was unnecessary from the start.2. CIAM JWT signing key (
SUPABASE_SIGNING_KEY_JSON+ ES256 signing keys)The CIAM design originally specced editor-minted ES256 JWTs verified by PostgREST via JWKS. That path was abandoned in favor of opaque,
sha256-hashed portal-session tokens resolved server-side viaservice_role(the live flow). The JWT scaffolding was left behind:editor/lib/ciam/server/jwt.ts—signCustomerSessionTokenhad zero callers.signing_keys_pathfromsupabase/config.toml(local Auth falls back to the default symmetricjwt_secret).gen signing-keystep (database-tests.yml) and thesigning_keys.json.gitignoreentry.grida_ciam.mdsections to describe the actual opaque-token model; JWT/JWKS now appears only as clearly-labeled, not-yet-implemented future work.No
.well-known/ JWKS / OIDC route ever existed in the repo — that part of the design never landed, so there was nothing to remove there.Behavior
No change for anything that runs. The
grida_ciamfeature itself stays live (opaque-token based); only the dead JWT-signing scaffolding is removed.Verification
turbo typecheck --filter=editor— passes (no orphaned imports of the deleted module).SUPABASE_URL_RR,rr(,SUPABASE_SIGNING_KEY_JSON,signCustomerSessionToken,signing_keys*) — zero matches.supabase stop && supabase start— comes up healthy withoutsigning_keys.json(Auth/health→ 200, all containers healthy).set_config, not signed JWTs, so they are unaffected.Summary by CodeRabbit
Refactor
Documentation