Supabase 42501 permission denied: tiesības, nevis RLS

Es izveidoju bezmaksas Supabase drošības pārbaudi, kas nolasa tiesības katrai atklātajai tabulai, un 42501 ir kļūda, ar ko cilvēki saskaras, kad tiesības ir nepareizas pretējā virzienā: par maz, nevis par daudz. Lūk, ko tas nozīmē un ko redzēju, kad to atkārtoju.

Ko nozīmē kļūda 42501 Supabase?

42501 ir Postgres kods nepietiekamām tiesībām (insufficient privilege). Postgres pārbauda divus slāņus, pirms klients pieskaras tabulai: tiesības (grants) nosaka, vai loma vispār drīkst veikt operāciju, un RLS politikas nosaka, kuras rindas. Trūkstošas tiesības izgāžas pirmās, kā kļūda. Politika, kas neatbilst nevienai rindai, izgāžas klusi, kā tukšs saraksts. Tāpēc, ieraugot 42501, skatieties uz tiesībām, nevis uz politikām.

PostgREST, Data API aiz supabase-js, kļūdu nodod tālāk ar norādi. Manā lokālajā vidē (Supabase CLI 2.109.1, Postgres 17.6, PostgREST 14.14) pieprasījums ar publishable key uz tabulu bez tiesībām lomai anon atgrieza HTTP 401 un:

{
  "code": "42501",
  "details": null,
  "hint": "Grant the required privileges to the current role with: GRANT SELECT ON public.orders TO anon;",
  "message": "permission denied for table orders"
}

Kāpēc jaunas tabulas pēc 2026. gada 30. oktobra saņem 42501?

Līdz šim jauna tabula shēmā public ar noklusējuma tiesībām (default privileges) saņēma select, insert, update un delete lomām anon, authenticated un service_role, tāpēc tā bija sasniedzama caur Data API no izveides brīža, aizsargāta vai nē. Supabase changelog šos noklusējumus noņem: izvēles iespēja no 2026. gada 28. aprīļa, noklusējums jauniem projektiem no 2026. gada 30. maija un piemērots visiem esošajiem projektiem 2026. gada 30. oktobrī. Esošās tabulas saglabā savas tiesības.

Ko vēl salauž pārslēgšana un kā projektu pārbaudīt iepriekš: Supabase 30. oktobra izmaiņas: kas salūzīs, kā pārbaudīt.

Tādu pašu izmaiņu pielietoju savam lokālajam projektam ar divām changelog norādītajām alter default privileges … revoke komandām un tad izveidoju jaunu tabulu invoices:

Pieprasījums uz jauno tabulu	Rezultāts
Publishable key, tiesību nav	HTTP 401, 42501, norāde GRANT SELECT ON public.invoices TO anon;
Secret key, tiesību nav	HTTP 403, 42501, norāde … TO service_role;
Publishable key, pēc grant select un enable row level security	HTTP 200, [], kamēr politika neatļauj rindas

Divas lietas mani pārsteidza. Secret key arī tiek atteikta: service_role apiet RLS, bet tai tomēr vajag tiesības, tāpēc Edge Function vai servera darbs, kas raksta jaunajā tabulā, salūst tāpat. Un revoke atņem tikai šīs četras operācijas: jaunā tabula joprojām nāca ar REFERENCES, TRIGGER un TRUNCATE tiesībām lomām anon, authenticated un service_role. Neviena politika neattiecas uz TRUNCATE.

Kā labot 42501, neatverot tabulu?

Uztveriet tiesības, RLS un politiku kā vienu izmaiņu, vienā migrācijā, un katrai lomai dodiet tikai to, kas tai vajadzīgs:

revoke all on table public.invoices from anon, authenticated;
grant select, insert, update on table public.invoices to authenticated;
grant select, insert, update, delete on table public.invoices to service_role;

alter table public.invoices enable row level security;

create policy "Owners read their invoices"
on public.invoices for select
to authenticated
using ((select auth.uid()) = user_id);

revoke all vispirms notīra TRUNCATE, TRIGGER un REFERENCES, kas nāca kopā ar tabulu. Neatbildiet uz 42501 ar grant all on all tables in schema public to anon: tas ir vecais noklusējums atpakaļ, visām tabulām uzreiz, un jebkura tabula bez RLS kļūst lasāma ikvienam, kam ir jūsu publiskā atslēga.

Ja jūsu tabulas veido AI rīks, liekiet tam izdot tiesības, RLS un politikas vienā migrācijā. Kļūdas norāde ir uzrakstīta tā, lai aģents pats varētu salabot tiesības, bet norāde nosauc tikai tiesības, nevis RLS, kam jānāk līdzi.

Kā to redz pārbaude?

Četri tās noteikumi nolasa tiesību slāni: “Noklusējuma tiesības, kas atver jaunus objektus API” atzīmē projektus, kas jaunas tabulas joprojām piešķir automātiski, “Neizmantotas rakstīšanas tiesības anonīmiem apmeklētājiem” atrod anon rakstīšanas tiesības, ko neizmanto neviena politika, un “Nevajadzīgas tabulu tiesības pieteikušamies lietotājiem” atrod TRUNCATE, TRIGGER un REFERENCES kā augstākminētās. “Politikas, kas nekad nedarbojas: lomai nav tiesību” uzskaita tabulas, kurās politika norāda lomu, kurai nav tiesību uz šo komandu, un tieši tā pēc 30. oktobra izskatās jauna tabula. Kāpēc RLS joprojām ir svarīgs pēc tiesību piešķiršanas, ir rakstā kā es testēju Supabase RLS, bet kā tiesības un politikas izskatās visā lietotnē, ir manā Lovable lietotnes drošības kontrolsarakstā.