feat: table for collecting interfaces feedback (#48420)

## 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?

Database migration — adds a table for collecting free-form product
feedback submitted from Supabase interfaces (starting with the CLI and
the MCP server), including support for deleting a submission via a
server-issued token.

## What is the current behavior?

There is no destination for feedback submitted from the CLI or MCP
server. The existing `feedback` and `feedback_comments` tables are
scoped to the docs feedback widget, so interface feedback would
otherwise end up as ad-hoc GitHub issues — with no way to revoke
something submitted by accident (e.g. a secret key pasted into the
message).

## What is the new behavior?

Adds `public.interfaces_feedback`:

| Column | Type | Notes |
| --- | --- | --- |
| `id` | `bigint` identity | primary key (not exposed through the API) |
| `created_at` | `timestamptz` | `not null default now()` |
| `feedback` | `text` | `not null`, ≤ 1000 chars — the free-form
feedback |
| `delete_token` | `uuid` | server-generated, `unique not null`;
authorizes deleting the row |
| `user_agent` | `text` | ≤ 255 chars; interface + version, also
identifies the source interface |
| `user_id` | `text` | optional, ≤ 255 chars; unverified,
interface-defined identifier |
| `project_ref` | `text` | optional, ≤ 255 chars |
| `metadata` | `jsonb` | ≤ 8 KB catch-all |

**Submission** happens exclusively through a `SECURITY DEFINER`
function, `submit_interfaces_feedback(...)`, which inserts the row and
returns the server-generated `delete_token` exactly once. There is no
insert grant or policy on the table itself, so clients cannot insert
directly or supply their own token — the function is the only door.
Execute is revoked from `PUBLIC` and granted to `anon` only (both
statements matter: local and hosted databases have different default
function ACLs).

**Deletion** is a hard `DELETE` authorized by presenting the token in an
`x-feedback-token` request header. RLS policies compare the row's
`delete_token` against that header (`current_setting('request.headers',
...)`) — the URL filter is never the security boundary; a request
without the matching header affects zero rows, even with no filter or
someone else's token in the filter. Tokens never expire (the delete
right shouldn't lapse). The header is cast to `uuid` and compared
against the untransformed column, so lookups use the unique index on
`delete_token` even for header-only reads; a malformed token header is
rejected with a `400` (`22P02`), consistent with what a malformed URL
filter value already returns.

**Context gate (defense-in-depth)**: rows submitted with a `project_ref`
and/or `user_id` additionally require the matching
`x-feedback-project-ref` / `x-feedback-user-id` headers — on both reads
and deletes — so a leaked bare token can neither read the submission
text back nor remove the row. A `NULL` column imposes no requirement:
context-free rows keep token-only behavior, and extra headers sent
against them are ignored (this keeps clients that always send their
current context from being locked out of rows submitted without it).
These are client-supplied, unverified values, so the gate is a knowledge
factor rather than an identity check; clients should persist
`{delete_token, project_ref, user_id}` together at submit time and
re-present them byte-exact (`project_ref`/`user_id` are compared as
plain text).

**Reads** are limited to `grant select (feedback, delete_token)` behind
the same token-scoped policy: a token-holder can preview their own
submission text before deleting and confirm the delete matched (`Prefer:
count=exact` → `Content-Range: */1` vs `*/0`). No other columns are
readable by any API role; `delete_token` needs select because PostgREST
requires a WHERE clause on deletes and filter columns require select
privilege.

Verified locally via `supabase db reset` + the local REST API: token
issuance, token-scoped preview and delete, zero-row results for
missing/wrong/malformed tokens (including a victim's token in the filter
without the header), the full context-gate matrix (project+user,
project-only, and context-free rows, incl. lenient extra-header
behavior), denied direct inserts and column reads, length caps enforced
through the function, and no execute for `authenticated`.

## Additional context

Linear tickets: [CLI-1946](https://linear.app/supabase/issue/CLI-1946),
[CLI-1999](https://linear.app/supabase/issue/CLI-1999)

The client-side flows (`supabase feedback add` / `feedback delete` in
the CLI, and the MCP tool) land separately in their respective repos and
will call the RPC / DELETE endpoint described above.

Supersedes #48378 — recreated on a fresh git branch so that the Supabase
preview branch used for testing this table isn't shared with unrelated
work.


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

* **New Features**
* Added support for collecting and storing feedback submitted through
interfaces.
* Feedback can include submission source, timestamps, user details,
project references, and additional metadata.
* Added secure feedback submission with controlled access to protect
submitted information.
* Added support for authorized feedback removal using a secure deletion
token.
* Added safeguards to validate feedback content and restrict access to
permitted information.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->

---------

Co-authored-by: Claude Fable 5 <noreply@anthropic.com>

supabase/migrations/20260728035858_create_interfaces_feedback.sql

@@ -0,0 +1,100 @@
+create table interfaces_feedback (
+	id bigint primary key generated always as identity,
+	created_at timestamptz not null default now(),
+	feedback text not null check (char_length(feedback) <= 1000),
+	delete_token uuid unique not null default gen_random_uuid(),
+	user_agent text check (char_length(user_agent) <= 255),
+	user_id text check (char_length(user_id) <= 255),
+	project_ref text check (char_length(project_ref) <= 255),
+	metadata jsonb check (pg_column_size(metadata) <= 8192)
+);
+
+comment on table interfaces_feedback is
+'General customer feedback submitted from Supabase interfaces such as the CLI and MCP server. Rows are inserted via submit_interfaces_feedback().';
+comment on column interfaces_feedback.feedback is
+'The free-form feedback text as submitted by the user.';
+comment on column interfaces_feedback.delete_token is
+'Server-generated capability token returned once by submit_interfaces_feedback(); presenting it via the x-feedback-token request header authorizes reading and deleting this row. Rows submitted with a project_ref and/or user_id additionally require the matching x-feedback-project-ref / x-feedback-user-id headers.';
+comment on column interfaces_feedback.user_agent is
+'User agent of the submitting interface, e.g. SupabaseCLI/2.3.4. Also identifies which interface the feedback came from.';
+comment on column interfaces_feedback.user_id is
+'Optional identifier of the submitting user, as reported by the interface. Unverified; format is interface-defined.';
+comment on column interfaces_feedback.project_ref is
+'Optional reference of the Supabase project the feedback relates to.';
+
+alter table interfaces_feedback enable row level security;
+
+-- The x-feedback-* request headers are the capability check: policies can
+-- only compare row data against session context (never a query's WHERE
+-- clause), so the values must arrive as headers. The token is always
+-- required; project_ref and user_id are additionally required when (and only
+-- when) the row was submitted with them — a null column imposes no
+-- requirement, and values must be re-presented byte-exact. The token column
+-- stays untransformed so lookups use its unique index; a malformed token
+-- header is rejected with a 400 (22P02), same as a malformed URL filter.
+create policy "Token holders can read their own feedback"
+on interfaces_feedback
+as permissive for select
+to anon
+using (
+	delete_token = (current_setting('request.headers', true)::json ->> 'x-feedback-token')::uuid
+	and (project_ref is null or project_ref = current_setting('request.headers', true)::json ->> 'x-feedback-project-ref')
+	and (user_id is null or user_id = current_setting('request.headers', true)::json ->> 'x-feedback-user-id')
+);
+
+create policy "Token holders can delete their own feedback"
+on interfaces_feedback
+as permissive for delete
+to anon
+using (
+	delete_token = (current_setting('request.headers', true)::json ->> 'x-feedback-token')::uuid
+	and (project_ref is null or project_ref = current_setting('request.headers', true)::json ->> 'x-feedback-project-ref')
+	and (user_id is null or user_id = current_setting('request.headers', true)::json ->> 'x-feedback-user-id')
+);
+
+-- Submissions go exclusively through this function so the delete token is
+-- always server-generated and returned exactly once to the submitter. There
+-- is deliberately no insert grant or policy on the table itself.
+create function public.submit_interfaces_feedback(
+	feedback text,
+	user_agent text default null,
+	user_id text default null,
+	project_ref text default null,
+	metadata jsonb default null
+)
+returns uuid
+security definer
+set search_path = ''
+language plpgsql
+as $$
+#variable_conflict use_variable
+declare
+	token uuid;
+begin
+	insert into public.interfaces_feedback (feedback, user_agent, user_id, project_ref, metadata)
+	values (feedback, user_agent, user_id, project_ref, metadata)
+	returning delete_token into token;
+	return token;
+end;
+$$;
+
+comment on function public.submit_interfaces_feedback is
+'Submits interface feedback and returns the delete token (issued exactly once).';
+
+-- Both lines are load-bearing, in different environments: locally, the
+-- default ACL gives new functions no EXECUTE at all (the grant is required);
+-- on prod, the built-in default gives EXECUTE to the PUBLIC pseudo-role (the
+-- revoke is required, and it must target public — revoking from anon or
+-- authenticated by name is a no-op).
+revoke execute on function public.submit_interfaces_feedback(text, text, text, text, jsonb) from public;
+grant execute on function public.submit_interfaces_feedback(text, text, text, text, jsonb) to anon;
+
+-- Two-gate model: these grants allow anon to ATTEMPT select/delete
+-- statements; the header-checked policies above decide which rows each
+-- statement can see. Column-scoped select keeps everything except the
+-- feedback text and the caller's own token unreadable. delete_token needs
+-- select because PostgREST rejects filterless deletes and WHERE columns
+-- require select privilege — clients send the token as both the filter and
+-- the header, and the policy stays the security boundary.
+grant select (feedback, delete_token) on table interfaces_feedback to anon;
+grant delete on table interfaces_feedback to anon;