## I have read the
[CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md)
file.
YES
## What kind of change does this PR introduce?
Bug fix, feature, docs update, ...
- Hide lints when exposed within local storage
- Revoke on roles
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added a GraphQL-exposure action in linter items that shows a
confirmation modal with the exact SQL, lets you revoke GraphQL access,
executes the operation, shows success/error toasts, and refreshes lint
results.
* Added an informational callout linking to database integration
settings when GraphQL exposure is detected.
* Lint actions now close the side panel and return the UI to the list
after completion.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Joshen Lim <joshenlimek@gmail.com>
This PR preps the monorepo for a migration to Tailwind v4:
- Bump all Tailwind dependencies and libraries to the latest possible
version, while still compatible with Tailwind 3.
- Cleans up obsolete Tailwind 3 specific options and configs.
- Cleans up unused CSS files and fixes the CSS imports.
- Migrates all `important` uses in `@apply` lines to using the `!`
prefix.
- Move `typography.css` to the `config` package and import it from the
apps.
- Migrated all occurrences of `flex-grow`, `flex-shrink`,
`overflow-clip` and `overflow-ellipsis` since they're deprecated and
will be removed in Tailwind 4.
- Make the default theme object typesafe in the `ui` package.
- Migrate all `bg-opacity`, `border-opacity`, `ring-opacity` and
`divider-opacity` to the new format where they're declared as part of
the property color.
- Bump and unify all imports of `postcss` dependency.
## Summary
Fixes
[FE-3080](https://linear.app/supabase/issue/FE-3080/self-hosted-studio-advisors-toolbar-shows-blank-panel).
On self-hosted Studio, opening the Advisors panel rendered an infinite
skeleton with no network traffic.
## Root cause
`useBannedIPsQuery` is gated by `IS_PLATFORM`. On self-hosted that
disables the query — and a disabled React Query v5 query keeps
`isPending: true` forever (only `isFetching` / `isLoading` go false).
`useAdvisorSignals` re-exports that `isPending`, and `AdvisorPanel`
folded it into its `isLoading` aggregate, pinning the panel into the
skeleton state in `AdvisorPanelBody`.
The other consumers were already designed around this — `AdvisorSection`
on the home page explicitly does not wait on signals, and
`AdvisorButton` only reads `data`. Only `AdvisorPanel` had the
regression, introduced in #44372.
## Fix
Drop `isSignalsActuallyLoading` from the panel's `isLoading` aggregate,
mirroring the existing `[Joshen]` "ignore signal errors" exclusion two
lines below and matching the home-page pattern.
## Test plan
- [x] Existing unit + integration tests pass (`AdvisorPanel.utils`,
`useAdvisorSignals`, `AdvisorSignals.integration` — 6/6)
- [x] Verify on self-hosted Studio: open the Advisors sidebar and
confirm lints render (or "no issues" empty state appears) instead of an
infinite skeleton
- [x] Verify on hosted Studio: lints, banned-IP signals, and
notifications still render together; loading skeleton still appears
while lints/notifications are in flight
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Bug Fixes**
* Improved loading state behavior in the Advisor Panel by excluding
signal queries from blocking the panel's display. The loading indicator
now only appears when actively fetching lints or notifications, allowing
faster visibility of available content.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## I have read the
[CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md)
file.
YES
## What kind of change does this PR introduce?
Feature — wires up three new advisor lints landed in splinter, and
updates the self-hosted SQL bundle for the existing
`pg_graphql_anon_table_exposed` lint to track splinter's correctness
fixes. Companion to `supabase/splinter` #160 (already merged) and #162
(test fix in flight).
## What is the current behavior?
Splinter's `main` now exposes four lints in the pg_graphql / SECURITY
DEFINER family:
- `pg_graphql_anon_table_exposed` (0026, existing) — wired into Studio
in #45253; SQL in `packages/pg-meta` is the original version that uses
`has_table_privilege` and the relkind set `('r','p','v','m')`.
- `pg_graphql_authenticated_table_exposed` (0027, new) — paired check
against the `authenticated` role. Studio renders any new finding without
a `lintInfoMap` entry as a row with no icon, no title mapping, and no
"Fix" CTA. Self-hosted users do not see the lint at all because
`packages/pg-meta` does not include it.
- `anon_security_definer_function_executable` (0028, new) — `SECURITY
DEFINER` function executable by `anon`. Same Studio + self-hosted gaps
as 0027.
- `authenticated_security_definer_function_executable` (0029, new) —
same against `authenticated`.
Splinter has also updated 0026 itself (PR #160) in two ways that need to
flow into the self-hosted SQL bundle:
1. **`relkind` filter:** `('r','p','v','m')` → `('r','v','m','f')`.
Drops partitioned table roots (pg_graphql does not expose them; their
leaf partitions are still covered as `'r'`) and adds foreign tables,
which pg_graphql does expose.
2. **Privilege predicate:** `has_table_privilege(role, oid, 'SELECT')` →
`EXISTS` over `pg_attribute` calling `has_column_privilege`. Catches
column-level grants such as `GRANT SELECT (col) ON t TO anon`, which
pg_graphql's introspection exposes but `has_table_privilege` missed.
Cloud projects auto-fetch `splinter.sql` via the platform mgmt-api's
`getLintSql` (1-hour cache TTL), so they pick up #160's lint and SQL
changes independently of this PR. This PR is about the Studio display
mapping and the self-hosted SQL bundle.
## What is the new behavior?
Two minimal additions, mirroring the integration shape of #45253.
### `apps/studio/components/interfaces/Linter/Linter.utils.tsx`
Three new entries appended to `lintInfoMap`:
- `pg_graphql_authenticated_table_exposed` — `Eye` icon (paired with the
existing `pg_graphql_anon_table_exposed` entry); link points to the
Table Editor scoped to `metadata.schema` + `metadata.name`; `linkText:
'View object'`; `category: 'security'`.
- `anon_security_definer_function_executable` — `Unlock` icon (signals
"this thing is callable when it shouldn't be"); link points to the
Database Functions browser scoped to `metadata.schema` +
`metadata.name`; `linkText: 'View function'`; `category: 'security'`.
- `authenticated_security_definer_function_executable` — same as 0028
against `authenticated`.
Each entry's `docsLink` points at the splinter-hosted lint doc.
### `packages/pg-meta/src/sql/studio/advisor/lints.ts`
The existing `pg_graphql_anon_table_exposed` SQL block is updated in
place to match the new splinter version: new `relkind` set, `case`
statement for `'f'`, and the `EXISTS` over `pg_attribute` privilege
check. Three new `union all` blocks are appended for 0027/0028/0029. The
function lints (0028/0029) include the `pgrst.db_schemas` filter
(mirroring lint `0023_sensitive_columns_exposed`) so findings are scoped
to schemas PostgREST actually exposes; the self-hosted query wrapper
already sets the GUC when `exposedSchemas` is passed
(`enrichLintsQuery`).
## Coverage of the four exposure paths
| Role | Tables/views/MVs/foreign tables | SECURITY DEFINER functions |
|------|---------|----------|
| `anon` | 0026 (existing, updated) | 0028 (new) |
| `authenticated` | 0027 (new) | 0029 (new) |
The 0026/0027 pair covers `pg_graphql` introspection visibility; the
0028/0029 pair covers RLS bypass via privileged function execution
through `/rest/v1/rpc` (and `/graphql/v1` for compatible return types).
Each lint's doc cross-references its sibling so an operator hitting one
is steered toward the others.
## Verification
- `cd packages/pg-meta && npx tsc --noEmit` — clean.
- `cd apps/studio && npx tsc --noEmit` — clean for the changed file.
(Other unrelated TS errors exist in the working tree but are
pre-existing and not introduced by this PR.)
- `cd apps/studio && npx eslint
components/interfaces/Linter/Linter.utils.tsx` — clean.
## Files
- `apps/studio/components/interfaces/Linter/Linter.utils.tsx` — adds
three `lintInfoMap` entries (0027, 0028, 0029).
- `packages/pg-meta/src/sql/studio/advisor/lints.ts` — updates the 0026
SQL block to match splinter's correctness fixes, appends 0027/0028/0029
SQL blocks.
## Related
- supabase/splinter#160 — adds 0027/0028/0029 and rewrites 0026
(merged).
- supabase/splinter#162 — fixes test setup for 0028/0029 (in flight;
does not affect the SQL shipped here).
- supabase/supabase#45253 — original 0026 Studio integration.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added security linting to detect authenticated-table exposure and
executable SECURITY DEFINER functions.
* Added signed-in visibility checks alongside anonymous checks.
* **Bug Fixes / Improvements**
* Improved relation type handling for accurate table/foreign/partition
classification.
* Switched to column-level privilege analysis for visibility.
* Improved entity naming shown in lints (includes function argument
display).
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Danny White <3104761+dnywh@users.noreply.github.com>
## I have read the
[CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md)
file.
YES
## What kind of change does this PR introduce?
Bug fix.
## What is the current behavior?
Advisor dismissals use `useLocalStorageQuery`. When advisor signals
pruning ran, it sometimes invoked `setDismissedKeys` even when nothing
needed to change (no-op updater returning the same array reference).
Separately, `useLocalStorageQuery` would still persist +
`invalidateQueries` even when the computed next value was
reference-equal to the current cached value.
When `useAdvisorSignals` is mounted in two places at once
(`AdvisorSection` + `AdvisorPanel`), those redundant invalidations /
subscriber churn could occasionally cascade into React’s “Maximum update
depth exceeded” error (often surfaced via Radix `composeRefs` in stack
traces). CI saw this as an unhandled error during
`AdvisorSignals.integration.test.tsx`.
## What is the new behavior?
- `useLocalStorageQuery` now **early-returns** when `Object.is(next,
current)` so no-op updates don’t write localStorage or invalidate the
query.
- `useAdvisorSignals` pruning effect now **short-circuits** unless there
is actually a stale banned-IP dismissal to remove.
## Additional context
Follow-up from #44372 (advisor signal items for banned IPs).
Tests run locally:
- `pnpm --filter studio exec vitest run
components/ui/AdvisorPanel/useAdvisorSignals.test.tsx
components/ui/AdvisorPanel/AdvisorSignals.integration.test.tsx
hooks/misc/__tests__/useLocalStorageQuery.test.ts`
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Bug Fixes**
* Enhanced handling of dismissed security alerts by preventing
unnecessary state updates for stale dismissals, significantly reducing
overhead and improving overall application performance.
* Optimized local storage operations to skip redundant writes to storage
and prevent triggering unnecessary cache updates and query invalidations
when stored data values remain unchanged from the previous operation.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## What kind of change does this PR introduce?
Feature. Resolves DEPR-430.
## What is the current behaviour?
The homepage Advisor summary, shared Advisor panel, and top-nav Advisor
indicator only surface lints and notifications. Banned IPs are not
represented as dismissible Advisor items, so network bans are easy to
miss unless a user visits Database Settings directly.
The `public bucket allows listing` warning is no longer part of this PR.
That warning will move to a follow-up Splinter `WARN` lint so it can
flow through the standard lint surfaces instead of a bespoke Studio
signal path.
## What is the new behaviour?
- adds a new Advisor `signal` source for banned IPs on the platform
homepage, in the shared Advisor panel, and in the top-nav Advisor
indicator
- keeps dismissals client-side only for now, scoped by project and exact
IP fingerprint
- keeps banned IP signals at `warning` severity because they still
indicate suspicious traffic and remain actionable if a user wants to
review or remove a ban
- leaves `/project/[ref]/advisors/security` as follow-up work because
that surface is still lint-native, and banned IPs are management-plane
signals rather than Splinter lints
| After |
| --- |
| <img width="1728" height="997" alt="Mallet Toolshed
Supabase-65A60B4A-107E-4D79-B9A8-23F754BEAB08"
src="https://github.com/user-attachments/assets/c08ecbbb-c302-43bd-81bb-6ba7eb18b7b3"
/> |
## Reviewer testing notes
1. Use a throwaway project.
2. Get the database connection string for that project.
3. Attempt to connect with the wrong password 3-4 times until you hit an
`ECONNREFUSED`-style error, which should mean your IP has been banned.
4. Refresh Studio and confirm the project overview shows the new `Banned
IP address` signal.
5. Open the Advisor Center and confirm:
- the top-nav Advisor dot turns warning yellow
- the signal detail shows `Entity`, `Issue`, and `Resolve`
- `Edit network bans`, `Dismiss`, and `Learn more` are present
6. Open Database Settings > Network bans and confirm your banned IP
appears there and can be unbanned.
7. Note that `/project/[ref]/advisors/security` will not show this item.
That page is still lint-only, and this banned IP work is a short-term
client-side signal rather than a true lint.
Longer term, we likely want a more durable event model here so banned
IPs can power notifications, webhooks, emails, and other project-level
alerts.
---------
Co-authored-by: kemal <hello@kemal.earth>
Co-authored-by: Charis Lam <26616127+charislam@users.noreply.github.com>
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-authored-by: Joshen Lim <joshenlimek@gmail.com>
## Context
Adjust advisor panel to not show "Project required" UI for the "All"
panel since messages do not require to be in a specific project
<img width="434" height="251" alt="image"
src="https://github.com/user-attachments/assets/8a999ca7-1a81-4c63-a6f7-c73cbdd676e3"
/>
Also adjusts the red dot for advisor center button to show if there's
critical notifications
## Context
Since moving notifications to the Advisors Panel, we've been sending
`org_slug` and `project_ref` to the GET notifications endpoint, which
resulted in certain notifications not being returned such as those that
are user specific (no org slug nor project ref)
Am opting to remove both slug and ref filters for the notifications as
the notifications should be on a user level (irregardless if you're
within a project or not) - the Advisor's Panel's button in the layout
header would also suggest that notifications in there are not tied to an
org or project
## To test
This one's a bit tricky to test unless you have notifications on
staging, but i've double checked on prod with a curl command that
removing the org slug and project ref filters returns the correct
notifications
* Bump the deps, refactor deprecated code.
* Migrate keepPreviousData usage.
* Migrate all uses of InfiniteQuery.
* Fix refetchInterval in queries.
* Migrate all use of isLoading to isPending in mutations.
* Fix accessing location in claim-project.
* Fix a bug in duplicate query keys.
* Migrate all queries to use isPending.
* Revert "Fix accessing location in claim-project."
This reverts commit 2a07df64b5.
* Revert the rss.xml file to master.
* default filters and state fix
* add created at
* text color
* small simplification
* always unregister sidebar
---------
Co-authored-by: Alaister Young <a@alaisteryoung.com>
Ali Waseem