---
title: "Supabase 42501 permission denied: õigus, mitte RLS"
description: "Miks Supabase annab tabelile vea 42501 permission denied, mis muutub 30. oktoobril 2026 ning milline õigus, RLS ja poliitika selle parandavad."
url: "https://madsalt.tech/et/notes/supabase-42501-permission-denied/"
author: "Denys Zaichenko"
language: "et"
published: 2026-10-26
---

# Supabase 42501 permission denied: õigus, mitte RLS

Lühidalt

`42501 permission denied for table …` tähendab, et rollil pole tabelil õigust (grant), seega peatab Postgres päringu enne, kui ükski RLS-poliitika jookseb. Alates 30. oktoobrist 2026 lõpetab Supabase olemasolevatel projektidel skeemi `public` uute tabelite automaatse andmise, nii et pärast seda loodud tabelid vastavad 42501-ga, kuni te neile õigused annate. Parandus on kolm käsku koos: õigus operatsioonidele, mida roll vajab, `enable row level security` ja poliitika. Ainult õiguse andmine ilma RLS-ita avab tabeli kõigile.

Ehitasin tasuta [Supabase'i turvakontrolli](https://madsalt.tech/et/tools/supabase-security-check/), mis loeb õigusi igal avaldatud tabelil, ja 42501 on viga, millega inimesed kokku puutuvad, kui õigused on valed vastupidises suunas: liiga vähe liiga palju asemel. Siin on, mida see tähendab ja mida nägin, kui seda reprodutseerisin.

## Mida tähendab viga 42501 Supabase'is?

42501 on Postgresi kood puuduvate õiguste jaoks (insufficient privilege). Postgres kontrollib kahte kihti, enne kui klient tabelit puudutab: õigused (grants) otsustavad, kas roll tohib operatsiooni üldse teha, ja RLS-poliitikad otsustavad, millised read. Puuduv õigus ebaõnnestub esimesena, veana. Poliitika, mis ei sobi mitte ühegi reaga, ebaõnnestub vaikselt, tühja loendina. Seega kui näete 42501, vaadake õigusi, mitte poliitikaid.

PostgREST, `supabase-js`-i taga olev Data API, annab vea edasi vihjega. Minu kohalikul pinul (Supabase CLI 2.109.1, Postgres 17.6, PostgREST 14.14) tagastas publishable key'ga päring tabelile, millel polnud rollile `anon` õigust, HTTP 401 ja:

```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"
}
```

## Miks saavad uued tabelid pärast 30. oktoobrit 2026 vea 42501?

Seni sai uus tabel skeemis `public` vaikeõiguste kaudu `select`, `insert`, `update` ja `delete` rollidele `anon`, `authenticated` ja `service_role`, seega oli see Data API kaudu kättesaadav hetkest, kui see loodi, kaitstud või mitte. Supabase'i [changelog](https://supabase.com/changelog/45329-breaking-change-tables-not-exposed-to-data-and-graphql-api-automatically) eemaldab need vaikeväärtused: valikuline alates 28. aprillist 2026, uute projektide vaikeväärtus alates 30. maist 2026 ja kõigile olemasolevatele projektidele rakendatud 30. oktoobril 2026. Olemasolevad tabelid säilitavad oma õigused.

Mida ümberlülitus veel katki teeb ja kuidas projekti enne kontrollida: [Supabase 30. oktoobri grantide muudatus: mis läheb katki](https://madsalt.tech/et/blog/supabase-october-30-grant-change/).

Rakendasin sama muudatuse oma kohalikule projektile kahe changelog'is oleva `alter default privileges … revoke` lausega ja lõin seejärel uue tabeli `invoices`:

![Mida uus tabel vastab pärast 30. oktoobrit 2026. Kohalik Supabase uute vaikeõigustega, üks päring igaühe kohta. Publishable key, õigust pole: create table → õigust pole → 42501, HTTP 401; Secret key, õigust pole: create table → õigust pole → 42501, HTTP 403; Pärast grant select ja enable RLS: grant select → RLS sees → 0 rida, HTTP 200.](https://madsalt.tech/charts/et/supabase-42501-permission-denied.svg)

*Minu reproduktsioon kohalikul Supabase'i pinul Supabase'i changelog'i vaikeõigustega, 23. oktoober 2026.*

| Päring uuele tabelile                                                 | Tulemus                                                           |
| --------------------------------------------------------------------- | ----------------------------------------------------------------- |
| Publishable key, õigust pole                                          | HTTP 401, 42501, vihje `GRANT SELECT ON public.invoices TO anon;` |
| Secret key, õigust pole                                               | HTTP 403, 42501, vihje `… TO service_role;`                       |
| Publishable key, pärast `grant select` ja `enable row level security` | HTTP 200, `[]`, kuni poliitika ridu lubab                         |

Kaks asja üllatasid mind. Secret key'd keelatakse samuti: `service_role` jätab RLS-i vahele, kuid vajab siiski õigust, seega läheb Edge Function või serveritöö, mis uude tabelisse kirjutab, samamoodi katki. Ja revoke võtab tagasi ainult need neli operatsiooni: uus tabel tuli endiselt koos `REFERENCES`, `TRIGGER` ja `TRUNCATE` õigustega rollidele `anon`, `authenticated` ja `service_role`. Ükski poliitika ei kehti `TRUNCATE`-ile.

## Kuidas parandada 42501 tabelit avamata?

Käsitlege õigust, RLS-i ja poliitikat ühe muudatusena, ühes migratsioonis, ning andke igale rollile ainult see, mida see vajab:

```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` kustutab esmalt `TRUNCATE`, `TRIGGER` ja `REFERENCES`, mis tabeliga kaasa tulid. Ärge vastake 42501-le käsuga `grant all on all tables in schema public to anon`: see on vana vaikeväärtus tagasi, kõigile tabelitele korraga, ja iga tabel ilma RLS-ita muutub loetavaks igaühele, kellel on teie avalik võti.

Kui teie tabeleid loob AI tööriist, öelge sellele, et see väljastaks õigused, RLS-i ja poliitikad samas migratsioonis. Vea vihje on kirjutatud nii, et agent saab õiguse ise parandada, kuid vihje nimetab ainult õigust, mitte RLS-i, mis sellega kaasas peaks käima.

## Kuidas kontroll seda näeb?

Neli selle reeglit loevad õiguste kihti: "Vaikeõigused, mis avavad uued objektid API-le" märgib projektid, mis annavad uusi tabeleid endiselt automaatselt, "Anonüümsete külastajate kasutamata kirjutusõigused" leiab `anon` kirjutusõigused, mida ükski poliitika ei kasuta, ja "Sisselogitud kasutajate tarbetud tabeliõigused" leiab `TRUNCATE`, `TRIGGER` ja `REFERENCES` nagu ülalolevad. "Poliitikad, mis ei tööta kunagi: rollil puudub grant" loetleb tabelid, kus poliitika nimetab rolli, millel pole selle käsu jaoks granti, ja just nii näeb uus tabel välja pärast 30. oktoobrit. Miks RLS loeb ka pärast õiguse andmist, on artiklis [kuidas Supabase'i RLS-i testida](https://madsalt.tech/et/blog/how-to-test-supabase-rls/), ja kuidas õigused ja poliitikad välja näevad kogu rakenduses, on minu [Lovable'i rakenduse turvanimekirjas](https://madsalt.tech/et/blog/lovable-app-security-checklist/).