--- title: "Supabase 42501 permission denied: tiesības, nevis RLS" description: "Kāpēc Supabase tabulai atgriež 42501 permission denied, kas mainās 2026. gada 30. oktobrī un kuras tiesības, RLS un politika to labo, atkārtots lokāli." url: "https://madsalt.tech/lv/notes/supabase-42501-permission-denied/" author: "Denys Zaichenko" language: "lv" published: 2026-10-26 --- # Supabase 42501 permission denied: tiesības, nevis RLS Īsumā `42501 permission denied for table …` nozīmē, ka lomai tabulā nav tiesību (grant), tāpēc Postgres aptur pieprasījumu, pirms darbojas jebkura RLS politika. No 2026. gada 30. oktobra Supabase esošajos projektos pārstāj automātiski piešķirt `public` shēmas jaunās tabulas, tāpēc pēc tam izveidotās tabulas atbild ar 42501, kamēr tām nepiešķirat tiesības. Labojums ir trīs komandas kopā: tiesības uz operācijām, ko loma prasa, `enable row level security` un politika. Tikai tiesību piešķiršana bez RLS atver tabulu ikvienam. Es izveidoju bezmaksas [Supabase drošības pārbaudi](https://madsalt.tech/lv/tools/supabase-security-check/), 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: ```json { "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](https://supabase.com/changelog/45329-breaking-change-tables-not-exposed-to-data-and-graphql-api-automatically) š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](https://madsalt.tech/lv/blog/supabase-october-30-grant-change/). 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`: ![Ko jauna tabula atbild pēc 2026. gada 30. oktobra. Lokāls Supabase ar jaunajām noklusējuma tiesībām, katrs pieprasījums vienreiz. Publishable key, tiesību nav: create table → tiesību nav → 42501, HTTP 401; Secret key, tiesību nav: create table → tiesību nav → 42501, HTTP 403; Pēc grant select un enable RLS: grant select → RLS ieslēgts → 0 rindu, HTTP 200.](https://madsalt.tech/charts/lv/supabase-42501-permission-denied.svg) *Mana reprodukcija lokālā Supabase vidē ar noklusējuma tiesībām no Supabase changelog, 2026. gada 23. oktobris.* | 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: ```sql 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](https://madsalt.tech/lv/blog/how-to-test-supabase-rls/), bet kā tiesības un politikas izskatās visā lietotnē, ir manā [Lovable lietotnes drošības kontrolsarakstā](https://madsalt.tech/lv/blog/lovable-app-security-checklist/).