## Context
Resolves FE-3221
Heavily inspired by what @filipecabaco has done previously here:
https://github.com/supabase/supabase/pull/45360
This PR explores the use of pglite to set up a sandbox for RLS testing,
which will pave the way for testing mutation based queries so to ensure
no disruption to the actual database. Sandbox can be set up within the
RLS tester panel as such:
<img width="500" alt="image"
src="https://github.com/user-attachments/assets/0cfdf8e4-dd99-4dee-ac00-39a32b375c07"
/>
Which the sandbox will mimic the project's database to the bare minimum
required
- entities from the `public` schema are copied over (types, tables,
functions, policies)
- `auth` schema is pseudo setup with `SANDBOX_SETUP_STATEMENTS`
- Enough to support role impersonation + querying tables with references
to the auth schema (e.g users table)
- data is seeded up to 100 rows for each table
- More info RE limitations in the last section below
Once sandbox is ready, you'll see this UI where you can either leave the
sandbox, or re-sync the sandbox from the actual database
<img width="500" alt="image"
src="https://github.com/user-attachments/assets/d07ce55f-5bc8-4722-8ce9-898b9b458f9b"
/>
Changes are currently feature flagged, so won't be available publicly
just yet until things are ironed out and ready
## To test
- [ ] Verify that setting up sandbox works
- [ ] Verify that you can query your sandbox, and queries do not touch
the actual database (can verify that we're not sending HTTP requests to
the /query endpoint)
- [ ] Verify correctness of RLS tester as well, should match correctness
with testing against actual DB
- [ ] Verify that re-syncing sandbox picks up changes
- Can test by updating your policies that will affect the output of your
select query
- e.g SELECT for `authenticated`, change from just `true` to `false`
- [ ] RLS tester should work as per normal (against actual DB) with the
feature flag off with no additional overhead
Let me know of any edge cases you might run into while testing
## Known quirks that will be addressed subsequently
Leaving these for now just to not bloat this PR further
- Pglite schema needs to be re-synced if updating RLS policies while
testing, to ensure that pglite gets the updated policies. Will think
about how to make this more seamless
- Sandbox has its own limitations, will need to add a dialog to inform
users how the sandbox works and what limitations to note of
- e.g only the auth schema is mimicked - so policies that reference
storage helpers won't work (although i think auth is probably the main
use case and the rest might be niche)
- We can slowly expand tho where required
- Eventually we'll also move forward with figuring out testing mutation
queries with this sandbox
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* RLS tester gains an isolated Postgres sandbox with schema/seed import,
start/refresh/exit controls, and pre-populated auth data.
* Sandbox management UI with setup, loading, active, and error states;
refresh and destroy actions.
* **Bug Fixes**
* Role impersonation now keeps the PostgREST role set to anon while the
tester sheet is open.
* **Chores**
* Content Security Policy updated to allow sandbox/connectivity
endpoints.
* **Style**
* Minor sheet styling adjustment (top border).
<!-- review_stack_entry_start -->
[](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/45839)
<!-- review_stack_entry_end -->
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Context
Missed another case here - RLS tester when retrieving policies
associated with query needs to consider policies with the `ALL`
operation
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Tests**
* Added comprehensive tests for Row-Level Security policy filtering,
covering schema/table matching, role handling (including
public/service-role cases), command/operation semantics, and combined
filter behavior.
* **Refactor**
* Centralized and clarified RLS policy filtering logic used by the
tester for improved maintainability and consistency.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Context
For a table that has RLS enabled, but a policy with just `true` for the
role `public`
The RLS tester was incorrectly reporting that `anon` doesn't have access
Was happening as we weren't considering policies that apply to the
`public` role (which applies to _all_ roles)
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Bug Fixes**
* RLS tester now treats explicitly-public policies as applicable
regardless of the impersonated role, improving policy coverage accuracy.
* **Refactor**
* Consolidated RLS test state computation to improve consistency of
access badges and policy messaging.
* **Tests**
* Added comprehensive tests validating RLS scenarios, badge states, and
policy/role messaging.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Mark provenance of SQL via the branded types SafeSqlFragment and
UntrustedSqlFragment. Only SafeSqlFragment should be executed;
UntrustedSqlFragments require some kind of implicit user approval (show
on screen + user has to click something) before they are promoted to
SafeSqlFragment.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Editor and RLS tester show loading states for inferred/generated SQL
and include a dedicated user SQL editor for safer edits.
* **Refactor**
* Platform-wide SQL handling tightened: snippets and AI-generated SQL
are treated as untrusted/display-only until promoted, improving safety
and consistency.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Context
As part of RLS testing, adding @awaseem's idea for having "View data as
user" CTAs in the Auth Users's table
<img width="348" height="190" alt="image"
src="https://github.com/user-attachments/assets/855c8f54-0aba-478c-982b-1d9d29e419bd"
/>
## Other changes
Similar from @awaseem's suggestions, am also refactoring the Role
Impersonation UI a little, mainly from a copy writing POV to improve the
clarity of the UI.
- More action-oriented and contextual header for the role impersonation
popover
- e.g Table Editor -> "View data as a role", or SQL Editor -> "Run SQL
query as a role"
- Updated labels to be bit more intuitive from a builder's POV
- The actual database role is still mentioned in the option's
description (so we aren't obfuscating the actual postgres logic)
- Add label descriptors to elaborate what each role implies
- e.g Anon -> "Not logged in"
- Add docs button which points to
[here](https://supabase.com/docs/guides/database/postgres/row-level-security#authenticated-and-unauthenticated-roles)
that explains which roles Supabase uses
- (Nit) Refactor to use Card component
### Before
<img width="647" height="277" alt="image"
src="https://github.com/user-attachments/assets/9ebae084-38b7-4e21-886b-f609bd71976e"
/>
### After
<img width="604" height="309" alt="image"
src="https://github.com/user-attachments/assets/4d797309-1b6b-4fd0-aab3-63d5e144c53c"
/>
<img width="630" height="297" alt="image"
src="https://github.com/user-attachments/assets/ca748635-c5da-4426-a9c3-8cb5aeef47a6"
/>
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added "View data as user" and "Run SQL as user" actions to user rows
to impersonate a user and jump to table or SQL views.
* Impersonation now surfaces an identity card in new tabs showing the
impersonated identity and a Stop button.
* **UI/UX Improvements**
* Impersonation panels accept customizable headers, show clearer role
labels (Postgres), richer role descriptions, condensed RLS copy,
in-panel docs link, simplified "Stop" labels, and adjusted
typography/padding for consistent styling.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Context
Resolves FE-3077
Related discussion: https://github.com/orgs/supabase/discussions/45233
Verifying the correctness of your RLS policies set up has always been a
gap, as highlighted by a number of GitHub discussions like
[here](https://github.com/orgs/supabase/discussions/12269) and
[here](https://github.com/orgs/supabase/discussions/14401). As such,
we're piloting a dedicated UI for RLS testing (using role impersonation
as the base), in which you'll be able to
- Run a SQL query as a user (not logged in / logged in - this is the
role impersonation part)
- See which RLS policies are being evaluated as part of the query
- And hopefully be able to debug which policies are not set up correctly
Changes are currently set as a feature preview - and we'll iterate as we
get feedback from everyone 🙂🙏
<img width="613" height="957" alt="image"
src="https://github.com/user-attachments/assets/83c37f8a-28fc-43b3-b0ff-e28571d8710c"
/>
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* RLS Tester: run queries as anon or authenticated users, view inferred
SQL, per-table policy summaries, and data previews of accessible rows.
* UI preview: new RLS Tester preview card and modal with opt-in toggle;
RLS Tester sheet with role/user selector and query editor.
* SQLEditor: “Explain” tab is always visible.
* **Chores**
* Added supporting API endpoints, background checks for table RLS
status, and a local-storage flag to persist the preview opt-in.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
