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

Man ir bezmaksas Supabase drošības pārbaude, 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, š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:

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.

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. 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ē.

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ā 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:

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:

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:

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:

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ā.

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 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.

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 iziet to soli pa solim, bet atklāto shēmu piezīme aptver citas shēmas, nevis public, ko šīs izmaiņas neskar.