---
title: "Supabase 30. oktobra izmaiņas: kas salūzīs, kā pārbaudīt"
description: "2026. gada 30. oktobrī Supabase pārstāj dot API tiesības jaunajām public tabulām esošajos projektos. Kas salūzīs, kas strādā un 4 pārbaudes, izmēģināts lokāli."
url: "https://madsalt.tech/lv/blog/supabase-october-30-grant-change/"
author: "Denys Zaichenko"
language: "lv"
published: 2026-10-26
---

# Supabase 30. oktobra izmaiņas: kas salūzīs, kā pārbaudīt

Īsumā

2026. gada 30. oktobrī Supabase katrā esošajā projektā pārstāj automātiski piešķirt lomām `anon`, `authenticated` un `service_role` tiesības jaunajām `public` tabulām. Tabulas, kas jums jau ir, turpina strādāt. Katra pēc tam izveidotā tabula uz `supabase-js` un jūsu secret key pieprasījumiem atbild ar `42501 permission denied`, kamēr migrācija nepiešķir tiesības. Pārslēgšanu atkārtoju lokāli: jaunas tabulas, jauni skati un vecas tabulas, ko migrācija izdzēš un izveido no jauna, nestrādā; esošās tabulas, RPC funkcijas un `serial` ievietošana strādā. Pārbaudei zemāk ir divi SQL vaicājumi un viens grep, bet labo ar tiesībām, RLS un politiku vienā migrācijā, nekad ar `grant all on all tables`.

Man ir bezmaksas [Supabase drošības pārbaude](https://madsalt.tech/lv/tools/supabase-security-check/), kas nolasa tiesības katrai atklātajai tabulai, tāpēc gribēju precīzi redzēt, ko šīs izmaiņas dara, pirms cilvēki sāk ar tām saskarties. Paņēmu lokālu Supabase stack, iedevu tam vecos noklusējumus, pielietoju pārslēgšanu tā, kā to apraksta Supabase, un nosūtīju pieprasījumu katram objekta veidam, ko varēju izdomāt. Šis raksts ir par to, ko saņēmu, un kā pārbaudīt savu projektu līdz 30. datumam.

## Kas mainās 2026. gada 30. oktobrī?

Līdz šim katra `public` shēmā izveidotā tabula caur Postgres noklusējuma tiesībām (default privileges) saņēma `select`, `insert`, `update` un `delete` lomām `anon`, `authenticated` un `service_role`. Tāpēc jauna tabula bija sasniedzama no pārlūka uzreiz pēc izveides, ar RLS vai bez tā. Supabase [paziņojums par izmaiņām, kas lauž saderību](https://supabase.com/changelog/45329-breaking-change-tables-not-exposed-to-data-and-graphql-api-automatically), šos noklusējumus noņem trīs posmos:

| Datums                  | Kas notiek                                                                             |
| ----------------------- | -------------------------------------------------------------------------------------- |
| 2026. gada 28. aprīlis  | Jauni projekti izveides brīdī var atteikties no „Automatically expose new tables“      |
| 2026. gada 30. maijs    | Jaunā uzvedība kļūst par noklusējumu jauniem projektiem, ieviešana ilgst dažas nedēļas |
| 2026. gada 30. oktobris | Jaunā uzvedība tiek piemērota visiem esošajiem projektiem                              |

Jūsu projektā pārslēgšana ir divi izteikumi, tie paši, ko Supabase dod tiem, kas vēlas pāriet agrāk:

```sql
alter default privileges for role postgres in schema public
  revoke select, insert, update, delete on tables from anon, authenticated, service_role;

alter default privileges for role postgres in schema public
  revoke usage, select on sequences from anon, authenticated, service_role;
```

Noklusējuma tiesības attiecas tikai uz vēlāk izveidotiem objektiem. Jau piešķirtās tiesības netiek mainītas, tāpēc jūsu pašreizējās tabulas turpina strādāt. Saskaņā ar paziņojumu izmaiņas neskar: citas shēmas (`auth`, `storage`, `realtime`, jūsu pašu), lietotnes, kas ar Postgres runā tiešā savienojumā (psql, ORM, serveris ar connection string), un pašu RLS. Izmaiņas attiecas uz Data API: REST, GraphQL un visām klientu bibliotēkām virs tiem.

## Kas salūzīs un kas turpina strādāt?

Mana vide: Supabase CLI 2.109.1, Postgres 17.6, PostgREST 14.14, 2026. gada 26. oktobris. `config.toml` iestatīju `auto_expose_new_tables = true`, lai iegūtu vecos noklusējumus, izveidoju vienu tabulu ar divām rindām, ieslēgtu RLS un lasīšanas politiku, tad palaidu augstāk redzamos divus izteikumus. Pēc tam izveidoju jaunus objektus un katru izsaucu ar lokālo publisko (`anon`) atslēgu un secret (`service_role`) atslēgu, pa vienam pieprasījumam.

![Kas pārstāj atbildēt pēc 30. oktobra pārslēgšanas. Lokāls Supabase, objekti izveidoti pēc changelog revoke, publiskā atslēga, ja nav norādīts citādi. Jauna tabula ar RLS un politiku: create table → politika, bez grant → 42501, HTTP 401; Tā pati tabula ar secret key: create table → politika, bez grant → 42501, HTTP 403; Jauns skats virs strādājošas tabulas: create view → 42501, HTTP 401, bez norādes; Vecā tabula, migrācijā dzēsta un izveidota no jauna: drop + create table → tiesības zudušas → 42501, HTTP 401.](https://madsalt.tech/charts/lv/supabase-october-30-grant-change.svg)

*Mans atkārtojums lokālā Supabase stack (CLI 2.109.1, Postgres 17.6, PostgREST 14.14), 2026. gada 26. oktobris.*

![Kas turpina strādāt pēc 30. oktobra pārslēgšanas. Tas pats lokālais stack, tas pats revoke, publiskā atslēga. Tabula, izveidota pirms pārslēgšanas: esoša tabula → tiesības saglabātas → 2 rindas, HTTP 200; Jauna funkcija, izsaukta caur RPC: create function → execute caur PUBLIC → HTTP 200; Jauna serial tabula, piešķirti tikai select un insert: id serial → sekvences UPDATE palika → insert, HTTP 201.](https://madsalt.tech/charts/lv/supabase-october-30-grant-change-works.svg)

*Mans atkārtojums lokālā Supabase stack (CLI 2.109.1, Postgres 17.6, PostgREST 14.14), 2026. gada 26. oktobris.*

| Objekts, izveidots pēc pārslēgšanas, ja nav norādīts citādi                | Atslēga | Rezultāts                                                            |
| -------------------------------------------------------------------------- | ------- | -------------------------------------------------------------------- |
| Tabula, izveidota pirms pārslēgšanas                                       | public  | HTTP 200, 2 rindas                                                   |
| Jauna tabula ar RLS un `to anon, authenticated` politiku                   | public  | HTTP 401, 42501, norāde `GRANT SELECT ON public.new_orders TO anon;` |
| Tā pati jaunā tabula                                                       | secret  | HTTP 403, 42501, norāde `… TO service_role;`                         |
| Jauns skats (`security_invoker`) virs vecās tabulas                        | public  | HTTP 401, 42501, `permission denied for view`, norāde `null`         |
| Kopija, izveidota ar `create table … (like old_orders including all)`      | public  | HTTP 401, 42501                                                      |
| Vecā tabula pēc `drop table` un atkārtota `create table`                   | public  | HTTP 401, 42501                                                      |
| Jauna funkcija `public.ping()` caur `/rest/v1/rpc`                         | public  | HTTP 200                                                             |
| Jauna tabula ar `id serial`, lomai `anon` piešķirti tikai `select, insert` | public  | insert HTTP 201                                                      |

Pieci šīs tabulas punkti ir vērts zināt pirms pārslēgšanas.

**„Esošās tabulas saglabā savas tiesības“ ir spēkā tikai tik ilgi, kamēr tabula pastāv.** Migrācija, kas izdzēš un no jauna izveido tabulu, `create table … (like …)` kopija vai atjaunošana no dump izveido jaunu tabulu, bet jauna tabula nesaņem neko. Politika atgriezās ar manu `create policy`, tiesības neatgriezās. Viss, kas jūsu pipeline tabulas pārbūvē, nevis maina, salūzīs pirmajā palaišanā pēc pārslēgšanas.

**Secret key arī salūzt.** `service_role` apiet RLS, bet tiesības tam tomēr vajag. Tātad Edge Function, cron darbs vai webhook apstrādātājs, kas raksta jaunā tabulā, saņem 403, ne tikai pārlūks. Norāde nosauc `service_role`, pēc tā to var atšķirt.

**Skati norādi nedod.** Tabulām PostgREST atgriež precīzo vajadzīgo `GRANT`. Manam jaunajam skatam norāde bija `null`, bet ziņojums skanēja `permission denied for view v_old_orders`. MI rīkam, kas labo 42501 pēc norādes, šeit nav ko kopēt; tiesības ir `grant select on public.v_old_orders to authenticated;`, un skatam jāpaliek ar `security_invoker = true`, lai tabulas RLS joprojām darbotos.

**Funkcijas šīs izmaiņas neskar.** Abi izteikumi attiecas uz tabulām un sekvencēm. Mana jaunā funkcija palika izsaucama ar `anon`, `authenticated` un `service_role`, jo Postgres piešķir `execute` katrai jaunai funkcijai lomai `PUBLIC`, un shēmas līmeņa revoke to nevar noņemt, kā skaidro [Supabase API drošības ceļvedis](https://supabase.com/docs/guides/api/securing-your-api). RPC izsaukumi pēc 30. oktobra turpina strādāt; tas arī nozīmē, ka jauna `security definer` funkcija ar jūsu publisko atslēgu ir izsaucama uzreiz pēc izveides.

**`serial` ievietošana strādāja bez sekvences tiesībām.** Daudzi padomi saka, ka `serial` id pēc pārslēgšanas vajag `grant usage on sequence … to authenticated`. Manā palaišanā ievietošana izdevās arī bez tā: revoke noņem `usage` un `select` jaunajām sekvencēm, bet `update` paliek, un `nextval` pietiek ar `update`. Ja atsaucat visas noklusējuma tiesības uz sekvencēm, kā dara pilnais revoke API drošības ceļvedī, `usage` tiesības jau vajag. Identity kolonnai (`generated by default as identity`) nevajag neko abos gadījumos.

Vēl viena lieta, ko revoke atstāj: jaunā tabula joprojām nāca ar `TRUNCATE`, `REFERENCES` un `TRIGGER` visām trim lomām, bet Postgres 17 noklusējumi ietver arī `MAINTAIN`. Neviena RLS politika neattiecas uz `TRUNCATE`. To aprakstīju [42501 piezīmē](https://madsalt.tech/lv/notes/supabase-42501-permission-denied/).

## Kur ar to sastopaties pirms 30. oktobra

Pārslēgšana jūsu hostētajā projektā notiks 30. datumā, bet trīs vietas jau uzvedas kā pēc tās.

**`supabase db reset` jaunā CLI.** CLI v2.102.0 pievienoja `[api] auto_expose_new_tables` failam `config.toml`. Versijā 2.109.1, ja atslēgas nav, mans tīrais stack jau bija ar jaunajiem noklusējumiem: tabulas saņēma tikai `MAINTAIN`, `REFERENCES`, `TRIGGER` un `TRUNCATE`, sekvences tikai `UPDATE`. Iestatot `true`, vecās tiesības atgriežas un tiek izdrukāts `api.auto_expose_new_tables is deprecated and will be removed on 2026-10-30`. Tāpēc, ja jūsu lokālās tabulas pēc reset joprojām strādā, vispirms pārbaudiet šo atslēgu. Tā ir arī lētākā vieta, kur testēt: noņemiet to, palaidiet reset, palaidiet lietotni.

**Preview zari un projekti, kas izveidoti kopš 30. maija.** Tie atkārto jūsu migrācijas ar jaunajiem noklusējumiem. Katra tabula, kuras migrācijā nav `grant`, tur jau ir nepieejama. [GitHub diskusijā](https://github.com/orgs/supabase/discussions/45329) cilvēki, kuriem ir viens projekts katram klientam, ziņo tieši par to: darbojošies projekti ir kārtībā, bet katrs jauns izvietojums no tām pašām migrācijām ir bojāts.

**Bāzes migrācija, kas atgriež veco noklusējumu.** Komentētājs tajā pašā diskusijā norāda, ka pirmā migrācija, izveidota ar `supabase db pull`, var saturēt `alter default privileges … grant all on tables to anon, authenticated, service_role`. Šo izteikumu palaidu pēc pārslēgšanas: nākamā izveidotā tabula atkal bija sasniedzama, HTTP 200. Lokāli tas slēpj problēmu. Piemērots jūsu hostētajam projektam, tas kluši atceļ izmaiņas, un katra nākotnes tabula atkal ir atvērta publiskajai atslēgai, ar RLS vai bez tā. Meklējiet savās migrācijās `alter default privileges` un izlasiet katru trāpījumu.

## Kā pārbaudīt projektu pirms 30. oktobra

Četras pārbaudes, no ātrākās līdz rūpīgākajai. Pirmās divas darbojas hostētā projekta SQL Editor.

### 1. Vai jūsu projekts jau ir pārslēgts?

Tas ir vaicājums no Supabase API drošības ceļveža. Tas parāda, ko saņems jauni objekti, ko `public` shēmā izveido `postgres`:

```sql
select
  case d.defaclobjtype
    when 'r' then 'tables'
    when 'S' then 'sequences'
    when 'f' then 'functions'
  end as object_type,
  a.grantee::regrole as role,
  string_agg(a.privilege_type, ', ' order by a.privilege_type) as privileges
from pg_default_acl d
cross join lateral aclexplode(d.defaclacl) a
where d.defaclrole = 'postgres'::regrole
  and d.defaclnamespace = 'public'::regnamespace
  and a.grantee in ('anon'::regrole, 'authenticated'::regrole, 'service_role'::regrole)
group by 1, 2
order by 1, 2;
```

Ja `tables` rindās ir `SELECT, INSERT, UPDATE, DELETE`, projekts vēl ir uz vecā noklusējuma un pārslēgsies 30. datumā. Ja redzams tikai `MAINTAIN, REFERENCES, TRIGGER, TRUNCATE` (vai nav rindu), jaunās tabulas jau ir slēgtas. To var redzēt arī Dashboard, Data API iestatījumos, „Automatically expose new tables“.

### 2. Kurām tabulām ir politika, bet nav tiesību?

Politika lomai, kurai nav tiesību uz šo komandu, nekad nedarbojas: pieprasījums izgāžas pirms RLS. Šis vaicājums uzskaita šādus pārus. Manā laboratorijā tas atrada jauno tabulu un no jauna izveidoto veco, un neko citu:

```sql
select p.schemaname || '.' || p.tablename as "table", r.role, p.cmd
from pg_policies p
cross join lateral unnest(case when 'public' = any(p.roles) then array['anon', 'authenticated']::name[] else p.roles end) as r(role)
join pg_class c on c.relname = p.tablename
join pg_namespace n on n.oid = c.relnamespace and n.nspname = p.schemaname
where p.schemaname = 'public'
  and r.role in ('anon', 'authenticated')
  and not has_table_privilege(r.role::text, c.oid,
        case p.cmd when 'ALL' then 'SELECT' else p.cmd end)
order by 1, 2, 3;
```

Palaidiet to pēc katras migrācijas, CI pret tīru `db reset` vai staging vidē. Veselā projektā tas neatgriež neko; pēc 30. datuma jebkura rinda ir tabula, kuru jūsu lietotne nevar sasniegt. Tas pārbauda tabulas līmeņa tiesības, tāpēc tabula, kas atvērta tikai ar kolonnu tiesībām (`grant select (id, name) on …`), šeit parādīsies, lai arī šīs kolonnas ir nolasāmas.

### 3. Kuras migrācijas izveido tabulu bez tiesībām?

Datubāze rāda tikai tabulas, kas pastāv. Migrācija, ko vēl neesat piemērojis, ir redzama tikai jūsu repozitorijā. Šis aptuvenais grep uzskaita katru `create table` mapē `supabase/migrations` bez `grant … on` tam pašam nosaukumam:

```bash
for t in $(grep -hioE 'create table( if not exists)? +[a-z0-9_."]+' supabase/migrations/*.sql | awk '{print $NF}' | sort -u); do
  grep -qiF "on $t " supabase/migrations/*.sql || grep -qiF "on table $t " supabase/migrations/*.sql || echo "no grant: $t"
done
```

Tā ir teksta atbilstība, nevis SQL parsēšana: tiesības, kas uzskaita vairākas tabulas vienā izteikumā, vai tabula, kas vienā vietā nosaukta bez shēmas, bet citā ar to, dos kļūdainu trāpījumu. Izlasiet katru izdrukāto rindu. Tabulām, ko sasniedz tikai servera kods ar tiešu savienojumu, tiesības nav vajadzīgas vispār.

### 4. Atkārtojiet visu ar jaunajiem noklusējumiem

Noņemiet `auto_expose_new_tables` no `config.toml`, palaidiet `supabase db reset` un palaidiet lietotni vai tās testus. Tas ir jūsu projekts pēc 30. datuma, plus svaiga katras tabulas kopija, kas ir grūtākais gadījums. Supabase arī uzskaita skartās tabulas Security Advisor un atzīmē Data API atvērumu Table Editor.

## Kā labot, neatverot katru tabulu

Rakstiet tiesības, RLS un politikas migrācijā, kas izveido tabulu, un katrai lomai dodiet tikai to, ko lietotne izmanto:

```sql
create table public.invoices (
  id bigint generated by default as identity primary key,
  user_id uuid not null default auth.uid(),
  total numeric not null
);

revoke all on table public.invoices from anon, authenticated, service_role;
grant select, insert 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);

create policy "Owners add their invoices"
on public.invoices for insert
to authenticated
with check ((select auth.uid()) = user_id);
```

Šo bloku palaidu tajā pašā lokālajā stack: pieteicies testa lietotājs ievietoja rindu un nolasīja to atpakaļ (HTTP 201, tad 200), publiskā atslēga bez sesijas saņēma 42501, un 2. pārbaude augstāk tabulu vairs neuzskaitīja. Pirmais `revoke all` notīra `TRUNCATE`, `TRIGGER` un `REFERENCES`, kas nāk līdzi jaunai tabulai, un dod to pašu rezultātu projektā, kas vēl nav pārslēgts. `anon` tiesības dodiet tikai datiem, kas paredzēti neautentificētiem apmeklētājiem, bet `service_role` tikai tad, ja servera kods šai tabulai izmanto secret key. Kā tiesības un politikas sader visā lietotnē, ir aprakstīts manā [Lovable lietotnes drošības kontrolsarakstā](https://madsalt.tech/lv/blog/lovable-app-security-checklist/).

Ko nedarīt, kad atnāk pirmā 42501:

- **Nepalaidiet `grant all on all tables in schema public to anon, authenticated`.** Tas vienlaikus atgriež veco noklusējumu katrai tabulai, ieskaitot tās, kurās RLS nekad nav ieslēgts, un tās kļūst nolasāmas ikvienam, kam ir jūsu publiskā atslēga. [42501 piezīme](https://madsalt.tech/lv/notes/supabase-42501-permission-denied/) parāda, kāpēc tiesības ir pirmā atslēga un RLS otrā.
- **Nepievienojiet atkal `alter default privileges … grant`.** Tā ir visu izmaiņu atcelšana.
- **Neizslēdziet RLS „testēšanai“ un nelieciet secret key frontend.** Secret key apiet RLS ikvienam, kas atver jūsu bundle; atšķirība starp atslēgām ir aprakstīta [anon key vs service role key](https://madsalt.tech/lv/blog/supabase-anon-key-vs-service-role-key/).

Ja jūsu migrācijas raksta MI rīks, pievienojiet tam vienu rindu instrukcijās: „katra jauna tabula public shēmā saņem skaidras tiesības katrai lomai, tajā pašā migrācijā ieslēdz row level security un politikas; nekad nepiešķir tiesības visām tabulām public shēmā“. Kļūdas norāde to iemāca tiesībām, bet nekad RLS, kas pie tām pieder.

## Jautājumi, ko cilvēki uzdod par izmaiņām

**Vai manas esošās tabulas pārstās strādāt 30. oktobrī?** Nē. Noklusējuma tiesības attiecas uz vēlāk izveidotiem objektiem, un manā palaišanā vecā tabula pēc pārslēgšanas atbildēja ar HTTP 200. Izņēmums ir tabula, ko jūsu migrācijas izdzēš un izveido no jauna.

**Vai man kaut kas jādara, ja es nekad neveidoju tabulas?** 30. datumā nē. Pārbaudiet nākamreiz, kad jūs, kolēģis vai MI rīks tādu pievieno, un pārbaudiet katru pipeline, kas veido projektus vai zarus no jūsu migrācijām.

**Vai tas ietekmē Edge Functions?** Jā, ja tās ar secret key izmanto `supabase-js` jaunā tabulā: arī `service_role` vajag tiesības. Funkcijas, kas savienojas ar Postgres tieši, netiek ietekmētas.

**Vai tas ietekmē RPC funkcijas, Storage vai Auth?** Šajās izmaiņās ne. Jaunas funkcijas paliek izsaucamas caur `PUBLIC`, un `storage` un `auth` nav `public` shēma.

**Vai varu pārslēgties agrāk?** Jā. Divi izteikumi sākumā ir pārslēgšana; palaidiet tos vispirms staging, tad production. Esošās tabulas saglabā tiesības, tāpēc strādājoša lietotne to nepamana, bet nākamā jaunā tabula uzreiz parāda, vai jūsu migrācijas ir gatavas.

## Kā to redz pārbaude

Pārbaude savienojas tikai lasīšanas režīmā un nolasa tiesības katrai tabulai jūsu atklātajās shēmās: kurās tabulās publiskā atslēga var rakstīt bez politikas, kurām tabulām RLS ir izslēgts un kuras noklusējuma tiesības joprojām dod katrai jaunai tabulai `TRUNCATE`, `REFERENCES` vai `TRIGGER`. Tā arī uzskaita katru politiku, kuras lomai nav tiesību uz šo komandu, tabulas, ko atrod 2. pārbaude, izņemot tās, kurās RLS ir izslēgts vai piešķirtas kolonnu tiesības. Tā neredz migrāciju failus, ko neesat piemērojis, tāpēc 3. pārbaude augstāk jums jāpalaiž pašiem. Ja neesat drošs par RLS, [kā testēt Supabase RLS](https://madsalt.tech/lv/blog/how-to-test-supabase-rls/) iziet to soli pa solim, bet [atklāto shēmu piezīme](https://madsalt.tech/lv/notes/supabase-exposed-schemas/) aptver citas shēmas, nevis `public`, ko šīs izmaiņas neskar.