mirror of
https://github.com/supabase/supabase.git
synced 2026-06-12 08:29:15 +08:00
create-pull-request/patch
5 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Mert YEREKAPAN
|
4c07df1a48 |
feat(studio): surface affected project in metric advisories (#46203)
## Summary Resolves [GROWTH-865](https://linear.app/supabase/issue/GROWTH-865) on the Studio side. Companion backend PR: [supabase/platform#33086](https://github.com/supabase/platform/pull/33086). Resource-exhaustion advisories (CPU, Disk IO, Memory) currently give users a list of identical-looking messages with no project context. This PR makes the affected project visible in the advisor panel and hardens the "Check consumption" deep-link. ### Changes **Advisor list view** — `AdvisorPanel.utils.ts`, `AdvisorPanel.types.ts`, `AdvisorPanel.tsx`, `AdvisorPanelBody.tsx` - `AdvisorNotificationItem` now carries `project_ref`. - `getAdvisorItemSecondaryText` accepts an optional `projectNameByRef` map and returns the resolved project name (falling back to the ref if the lookup hasn't loaded). Falls through to the existing date string for notifications without a project. - `AdvisorPanel.tsx` builds the map from `useProjectsInfiniteQuery` and threads it through `AdvisorPanelBody`. **NotificationDetail** — `NotificationDetail.tsx` - `[ref]` / `[slug]` substitution in action URLs falls back to `data.project_ref` / `data.org_slug` before the `_` literal. This fixes the universal-link bug Tim reported where "Check consumption" sometimes resolved to `/project/_/...` while `useProjectDetailQuery` was still loading. The companion backend PR updates the notification copy so the title/message also name the project. Both PRs degrade gracefully if landed independently. ## Test plan - [x] `pnpm test:studio -- AdvisorPanel.utils.test.ts` — 6/6 pass (4 new tests cover the notification branch of `getAdvisorItemSecondaryText`) - [x] `pnpm typecheck` passes for apps/studio - [x] `pnpm exec eslint components/ui/AdvisorPanel/` passes - [ ] Local Studio smoke test: open Advisor → Messages, confirm project name shows under each notification and "Check consumption" deep-links to the correct project even if the project detail query is slow <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Advisor Panel notifications now display resolved project names when available for clearer context. * **Bug Fixes** * Notification action URLs now prefer stored project and organization refs/slugs with improved fallbacks, making action links more reliable. <!-- review_stack_entry_start --> [](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/46203?utm_source=github_walkthrough&utm_medium=github&utm_campaign=change_stack) <!-- review_stack_entry_end --> <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
samrose
|
4afbe9c2b2 |
feat: lint integration for pg_graphql introspection + SECURITY DEFINER functions (#45260)
## 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> |
||
|
Danny White
|
b721a2d780 |
feat(studio): advisor signal items for banned IPs (#44372)
## 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> |
||
|
Charis
|
4a0bb36ca8 |
style: require sorted imports in studio/components (#44408)
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> Co-authored-by: Ivan Vasilov <vasilov.ivan@gmail.com> |
||
|
Saxon Fletcher
|
986f3464a6 |
Advisor refine (#40293)
* advisor panel title * refactor * use badge for critical * Update apps/studio/components/ui/AdvisorPanel/AdvisorPanel.utils.ts Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> * refactor --------- Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> |
