---
title: "Supabase exposed schemas: ką atveria šis sąrašas"
description: "Ką Supabase reiškia nustatymas Exposed schemas, kaip mano saugos tikrintuvas vertina papildomas schemas ir viena SQL užklausa, randanti lenteles be RLS."
url: "https://madsalt.tech/lt/notes/supabase-exposed-schemas/"
author: "Denys Zaichenko"
language: "lt"
published: 2026-10-22
---

# Supabase exposed schemas: ką atveria šis sąrašas

Trumpai

Supabase sąrašas Exposed schemas nusprendžia, kurias schemas Data API pateikia kiekvienam, turinčiam jūsų viešąjį raktą. Numatytosios yra `public` ir `graphql_public`. Kiekviena lentelė, view ir funkcija schemoje, esančioje šiame sąraše, turi turėti savo teises ir RLS, todėl kiekviena papildoma schema yra dar vienas ginamas paviršius. Laikykite sąrašą trumpą ir tikrinkite jį pirmiausia.

Sukūriau nemokamą [Supabase saugos tikrintuvą](https://madsalt.tech/lt/tools/supabase-security-check/), o Exposed schemas sąrašas yra vienas pirmųjų dalykų, kuriuos jis skaito. Kai manęs paklausia, kiek saugus Supabase projektas, pradedu būtent nuo šio nustatymo.

## Ką Supabase reiškia „exposed" schema?

Supabase pateikia jūsų duomenų bazę per REST su PostgREST. PostgREST atsako tik už schemas iš savo `db_schema` sąrašo, kurį keičiate Dashboard skiltyje Project Settings → Data API → Exposed schemas. Projekto konfigūracijoje, kurią mačiau, reikšmė buvo `public,graphql_public`, o Supabase [vadove apie savo schemas](https://supabase.com/docs/guides/api/using-custom-schemas) rašoma, kad `public` pateikiama pagal numatytuosius nustatymus. Užklausa dėl schemos ne iš sąrašo atmetama, o [PostgREST](https://docs.postgrest.org/en/stable/references/api/schemas.html) niekada neleidžia sąraše turėti `pg_catalog` ar `information_schema`.

## Kodėl šis sąrašas svarbus?

Viskas pateiktoje schemoje pasiekiama viešuoju raktu: lentelės, view ir funkcijos. Supabase [RLS vadovas](https://supabase.com/docs/guides/database/postgres/row-level-security) sako tiesiai: lentelė pateiktoje schemoje be RLS yra skaitoma ir rašoma bet kuriai rolei, turinčiai į ją teisę. Schema, kurios sąraše nėra, per API nepasiekiama visai.

Taigi papildoma schema nėra neutralus pakeitimas. Įtraukus į sąrašą `storage` ar `vault`, vidinės lentelės atsiduria Data API pasiekiamumo ribose. Įtraukus savo schemą, kiekvienai joje esančiai lentelei reikia tokio pat dėmesio kaip `public`.

![Ką atveria papildoma pateikiama schema. Viena anon užklausa, prieš sutrumpinant sąrašą ir po to. Prieš: papildoma schema pateikiama: anon užklausa → Data API → papildoma schema → lentelė be RLS skaitoma; Po: tik public ir graphql_public: anon užklausa → Data API → tik numatytosios schemos → RLS visose lentelėse.](https://madsalt.tech/charts/lt/supabase-exposed-schemas.svg)

*Iš Supabase saugos tikrintuvo taisyklių ir Supabase Data API dokumentacijos, 2026 m. spalio 22 d.*

## Kaip tikrintuvas vertina sąrašą?

Patikra vadinasi `extra_exposed_schemas`. Papildoma laikoma viskas, išskyrus `public` ir `graphql_public`, toliau:

- Vidinė Supabase schema sąraše (`auth`, `storage`, `realtime`, `vault`, `extensions` ir panašios) yra **fail, aukšta svarba**.
- Tik savos schemos, pavyzdžiui `api`, duoda **įspėjimą, vidutinė svarba**.
- Be papildomų schemų patikra praeina.

Tas pats sąrašas valdo ir kitas patikras. Lentelės su išjungtu RLS, anon rašymo teisės, visada teisingos politikos, view be `security_invoker` ir `SECURITY DEFINER` funkcijos, kurias gali kviesti anon, pranešamos tik pateiktoms schemoms, nes būtent ten viešasis raktas jas pasiekia.

## Kaip saugiai naudoti savo schemą?

Sava schema yra teisėtas modelis: Supabase vadove [Securing your API](https://supabase.com/docs/guides/api/securing-your-api) atskira schema, pavyzdžiui `api`, aprašoma kaip būdas pateikiamą paviršių lengviau atpažinti ir tikrinti, o vidines lenteles laikyti schemose, kurios nepateikiamos. Veikia dviem žingsniais, ir abu nurodyti [vadove apie savo schemas](https://supabase.com/docs/guides/api/using-custom-schemas): pridėkite schemą prie Exposed schemas, tada suteikite rolėms `anon`, `authenticated` ir `service_role` teisę `usage` į schemą ir teises į jos objektus.

Vadovo pavyzdys suteikia `ALL` kiekvienai lentelei. Tos eilutės nekopijuočiau tokios, kokia yra. Vadove Securing your API rašoma, kad kiekviena rolė gautų tik tai, ko jai būtina reikia, ir kad RLS būtų įjungtas kiekvienoje pateikiamoje lentelėje. Teisės nusprendžia, ar rolė gali liesti lentelę, o politikos nusprendžia, kurias eilutes.

Dar vienas atskiras pakeitimas: Supabase [nebeprideda naujų `public` lentelių prie Data API automatiškai](https://supabase.com/changelog/45329-breaking-change-tables-not-exposed-to-data-and-graphql-api-automatically). Naujiems projektams tai numatytoji tvarka nuo 2026 m. gegužės 30 d., o esamiems projektams bus taikoma 2026 m. spalio 30 d., esamos lentelės teises išsaugo. Tai teisių sluoksnis. Jis nekeičia to, kurios schemos yra sąraše.

## Kaip patikrinti savo projektą?

Atidarykite Project Settings → Data API ir perskaitykite Exposed schemas. Jei ten daugiau nei `public` ir `graphql_public`, paklauskite, kam skirta kiekviena papildoma schema.

Tada išvardykite tose schemose esančias lenteles su išjungtu RLS ir pažiūrėkite, ar `anon` jau gali jas skaityti:

```sql
select n.nspname as schema,
       c.relname as "table",
       has_table_privilege('anon', c.oid, 'select') as anon_can_select
from pg_class c
join pg_namespace n on n.oid = c.relnamespace
where n.nspname in ('public', 'api')  -- your Exposed schemas
  and c.relkind in ('r', 'p')
  and not c.relrowsecurity
order by 1, 2;
```

Paleidau ją laikinoje Postgres 17 su schema `api`, kurioje buvo viena lentelė su RLS ir viena be jo, ir `public` lentele be RLS. Grąžino tik tas dvi be RLS:

```text
 schema | table  | anon_can_select
--------+--------+-----------------
 api    | orders | t
 public | logs   | t
```

Kiekviena eilutė, kurioje `anon_can_select` yra tiesa, yra lentelė, kurią gali skaityti bet kas, turintis jūsų viešąjį raktą, kol neįjungsite RLS arba neatimsite teisės. Užklausa apima tik lenteles. View ir funkcijoms reikia atskiros patikros, ją aprašo mano [Lovable programos saugos sąrašas](https://madsalt.tech/lt/blog/lovable-app-security-checklist/), o [kaip testuoju Supabase RLS](https://madsalt.tech/lt/blog/how-to-test-supabase-rls/) parodo, kaip įrodyti, kad politikos veikia.