Megosztás:

Lakebase Data API

Fontos

A Lakebase automatikus skálázása bétaverzióban érhető el a következő régiókban: eastus2, , westeuropewestus.

A Lakebase automatikus skálázása a Lakebase legújabb verziója automatikus skálázási számítással, skálázással nullára, elágaztatással és azonnali visszaállítással. A Lakebase Provisioned szolgáltatással való összehasonlításához tekintse meg a verziók közötti választást.

A Lakebase Data API egy PostgREST-kompatibilis RESTful felület, amely lehetővé teszi a Lakebase Postgres-adatbázissal való közvetlen interakciót szabványos HTTP-metódusokkal. Az adatbázissémából származtatott API-végpontokat kínál, amelyek lehetővé teszik a biztonságos CRUD-(létrehozási, olvasási, frissítési, törlési) műveleteket az adatokon anélkül, hogy egyéni háttérrendszer-fejlesztésre lenne szükség.

Áttekintés

A Data API automatikusan hoz létre RESTful végpontokat az adatbázisséma alapján. Az adatbázis minden táblája HTTP-kérésekkel válik elérhetővé, így a következőkre van lehetőség:

  • Adatok lekérdezése HTTP-kérésekkel GET rugalmas szűréssel, rendezéssel és lapszámozással
  • Rekordok beszúrása HTTP POST-kérésekkel
  • Rekordok frissítése HTTP PATCH- vagy PUT-kérésekkel
  • Rekordok törlése HTTP DELETE-kérésekkel
  • Függvények végrehajtása RRP-ként HTTP POST-kérések használatával

Ez a megközelítés szükségtelenné teszi az egyéni API-kód írását és karbantartását, így az alkalmazáslogikára és az adatbázissémára összpontosíthat.

PostgREST kompatibilitás

A Lakebase Data API kompatibilis a PostgREST specifikációval. Ön megteheti:

  • Meglévő PostgREST-ügyfélkódtárak és -eszközök használata
  • A PostgREST-konvenciók követése szűréshez, rendezéshez és lapozáshoz
  • A PostgREST-közösség dokumentációinak és példáinak adaptálása

Megjegyzés:

A Lakebase Data API az Azure Databricks implementációja, amelyet úgy terveztek, hogy kompatibilis legyen a PostgREST specifikációjával. Mivel a Data API független implementáció, a Rendszer nem tartalmaz olyan PostgREST-funkciókat, amelyek nem alkalmazhatók a Lakebase-környezetre. A funkciókompatibilitásról további információt a Funkciókompatibilitási referencia című témakörben talál.

Az API-funkciókkal, lekérdezési paraméterekkel és képességekkel kapcsolatos átfogó részletekért tekintse meg a PostgREST API referenciáját.

Használati esetek

A Lakebase Data API ideális a következőkhöz:

  • Webalkalmazások: Olyan előtérrendszereket hozhat létre, amelyek HTTP-kérésekkel közvetlenül kommunikálnak az adatbázissal
  • Mikroszolgáltatások: Egyszerűsített szolgáltatások létrehozása, amelyek REST API-k használatával férnek hozzá az adatbázis-erőforrásokhoz
  • Kiszolgáló nélküli architektúrák: Integrálás kiszolgáló nélküli függvényekkel és peremhálózati számítástechnikai platformokkal
  • Mobilalkalmazások: Közvetlen adatbázis-hozzáférés biztosítása a mobilalkalmazásokhoz RESTful felületen keresztül
  • Külső integrációk: Az adatok biztonságos olvasásának és írásának engedélyezése külső rendszerek számára

A Data API beállítása

Ez a szakasz végigvezeti a Data API beállításán, a szükséges szerepkörök létrehozásától az első API-kérés elkészítéséig.

Előfeltételek

A Data API-hoz egy Lakebase Postgres automatikus skálázási adatbázisprojekt szükséges. Ha nem rendelkezik ilyennel, tekintse meg az adatbázisprojektek használatának első lépéseit.

Jótanács

Ha mintatáblákra van szüksége a Data API teszteléséhez, hozza létre őket a Data API engedélyezése előtt. A mintaséma egy teljes példasémát mutat be.

A Data API engedélyezése

A Data API egyetlen Postgres-szerepkörön authenticatorkeresztül teszi elérhetővé az összes adatbázist, ami csak a bejelentkezéshez igényel engedélyeket. Ha a Data API-t a Lakebase-alkalmazáson keresztül engedélyezi, a rendszer automatikusan létrehozza ezt a szerepkört és a szükséges infrastruktúrát.

Az adat API engedélyezése:

  1. Lépjen a Data API lapjára a projektben.
  2. Kattintson az Adat API engedélyezése elemre.

A Data API engedélyezése gomb

Ez automatikusan végrehajtja az összes beállítási lépést, beleértve a authenticator szerepkör létrehozását, a pgrst séma konfigurálását és a public séma API-val való felfedését.

Megjegyzés:

Ha további sémákat kell elérhetővé tennie (túl public), módosíthatja a közzétett sémákat az Advanced Data API beállításai között.

A Data API engedélyezése után

A Data API engedélyezése után a Lakebase-alkalmazás két fülkel jeleníti meg a Data API-oldalt : API és Beállítások.

Data API-oldal az API URL-címének és biztonsági beállításainak megjelenítéséhez

Az API lap a következőket biztosítja:

  • API URL: Az alkalmazáskódban és API-kérelmekben használandó REST-végpont URL-címe. A megjelenített URL-cím nem tartalmazza a sémát, ezért API-kérések végrehajtásakor hozzá kell fűznie a séma nevét (például /public) az URL-címhez.
  • Sémagyorsítótár frissítése: Az API sémagyorsítótárának frissítésére használható gomb az adatbázisséma módosítása után. Lásd: Sémagyorsítótár frissítése.
  • Adatok védelme: A Postgres sorszintű biztonságának (RLS) a táblákhoz való engedélyezésének lehetőségei. Lásd: Sorszintű biztonság engedélyezése.

A Beállítások lapon konfigurálhatja az API viselkedését, például a közzétett sémákat, a maximális sorokat, a CORS-beállításokat stb. Lásd: Advanced Data API-beállítások.

Mintaséma (nem kötelező)

A dokumentációban szereplő példák a következő sémát használják. Létrehozhat saját táblákat, vagy használhatja ezt a mintasémát tesztelésre. Futtassa ezeket az SQL-utasításokat a Lakebase SQL Editor vagy bármely SQL-ügyfél használatával:

-- Create clients table
CREATE TABLE clients (
  id SERIAL PRIMARY KEY,
  name TEXT NOT NULL,
  email TEXT UNIQUE NOT NULL,
  company TEXT,
  phone TEXT,
  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

-- Create projects table with foreign key to clients
CREATE TABLE projects (
  id SERIAL PRIMARY KEY,
  name TEXT NOT NULL,
  description TEXT,
  client_id INTEGER NOT NULL REFERENCES clients(id) ON DELETE CASCADE,
  status TEXT DEFAULT 'active',
  start_date DATE,
  end_date DATE,
  budget DECIMAL(10,2),
  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

-- Create tasks table with foreign key to projects
CREATE TABLE tasks (
  id SERIAL PRIMARY KEY,
  title TEXT NOT NULL,
  description TEXT,
  project_id INTEGER NOT NULL REFERENCES projects(id) ON DELETE CASCADE,
  status TEXT DEFAULT 'pending',
  priority TEXT DEFAULT 'medium',
  assigned_to TEXT,
  due_date DATE,
  estimated_hours DECIMAL(5,2),
  actual_hours DECIMAL(5,2),
  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

-- Insert sample data
INSERT INTO clients (name, email, company, phone) VALUES
  ('Acme Corp', 'contact@acme.com', 'Acme Corporation', '+1-555-0101'),
  ('TechStart Inc', 'hello@techstart.com', 'TechStart Inc', '+1-555-0102'),
  ('Global Solutions', 'info@globalsolutions.com', 'Global Solutions Ltd', '+1-555-0103');

INSERT INTO projects (name, description, client_id, status, start_date, end_date, budget) VALUES
  ('Website Redesign', 'Complete overhaul of company website with modern design', 1, 'active', '2024-01-15', '2024-06-30', 25000.00),
  ('Mobile App Development', 'iOS and Android app for customer management', 1, 'planning', '2024-07-01', '2024-12-31', 50000.00),
  ('Database Migration', 'Migrate legacy system to cloud database', 2, 'active', '2024-02-01', '2024-05-31', 15000.00),
  ('API Integration', 'Integrate third-party services with existing platform', 3, 'completed', '2023-11-01', '2024-01-31', 20000.00);

INSERT INTO tasks (title, description, project_id, status, priority, assigned_to, due_date, estimated_hours, actual_hours) VALUES
  ('Design Homepage', 'Create wireframes and mockups for homepage', 1, 'in_progress', 'high', 'Sarah Johnson', '2024-03-15', 16.00, 8.00),
  ('Setup Development Environment', 'Configure local development setup', 1, 'completed', 'medium', 'Mike Chen', '2024-02-01', 4.00, 3.50),
  ('Database Schema Design', 'Design new database structure', 3, 'completed', 'high', 'Alex Rodriguez', '2024-02-15', 20.00, 18.00),
  ('API Authentication', 'Implement OAuth2 authentication flow', 4, 'completed', 'high', 'Lisa Wang', '2024-01-15', 12.00, 10.50),
  ('User Testing', 'Conduct usability testing with target users', 1, 'pending', 'medium', 'Sarah Johnson', '2024-04-01', 8.00, NULL),
  ('Performance Optimization', 'Optimize database queries and caching', 3, 'in_progress', 'medium', 'Alex Rodriguez', '2024-04-30', 24.00, 12.00);

Felhasználói engedélyek konfigurálása

Az összes Data API-kérést hitelesítenie kell az Azure Databricks OAuth-jogkivonatokkal, amelyeket a fejlécen keresztül küld el.Authorization A Data API korlátozza a hitelesített Azure Databricks-identitásokhoz való hozzáférést, az alapul szolgáló engedélyeket pedig a Postgres szabályozza.

A authenticator szerepkör az API-kérések feldolgozásakor feltételezi a kérelmező felhasználó identitását. Ahhoz, hogy ez működjön, minden, a Data API-t elérő Azure Databricks-identitásnak megfelelő Postgres-szerepkörrel kell rendelkeznie az adatbázisban. Ha először hozzá kell adnia felhasználókat az Azure Databricks-fiókjához, olvassa el a Felhasználók hozzáadása a fiókhoz című témakört.

Postgres-szerepkörök hozzáadása

A bővítmény használatával databricks_auth olyan Postgres-szerepköröket hozhat létre, amelyek megfelelnek az Azure Databricks-identitásoknak:

Hozza létre a bővítményt:

CREATE EXTENSION IF NOT EXISTS databricks_auth;

Postgres-szerepkör hozzáadása:

SELECT databricks_create_role('user@databricks.com', 'USER');

Részletes útmutatásért lásd: OAuth-szerepkör létrehozása Azure Databricks-identitáshoz SQL használatával.

Fontos

Ne használja az adatbázis-tulajdonosi fiókot (a Lakebase-projektet létrehozó Azure Databricks-identitást) a Data API eléréséhez. A authenticator szerepkörhöz szükség van a szerepkör betöltésére, és ez az engedély nem adható emelt szintű jogosultságokkal rendelkező fiókokhoz.

Ha megkísérli megadni az adatbázis-tulajdonosi szerepkört authenticator, a következő hibaüzenet jelenik meg:

ERROR:  permission denied to grant role "db_owner_user@databricks.com"
DETAIL:  Only roles with the ADMIN option on role "db_owner_user@databricks.com" may grant this role.

Engedélyek megadása a felhasználóknak

Most, hogy létrehozta a megfelelő Postgres-szerepköröket az Azure Databricks-identitásokhoz, engedélyeket kell adnia ezekhez a Postgres-szerepkörökhöz. Ezek az engedélyek szabályozzák, hogy az egyes felhasználók mely adatbázis-objektumokkal (sémákkal, táblákkal, sorozatokkal, függvényekkel) kommunikálhatnak API-kérésekkel.

Engedélyek megadása standard SQL-utasítások GRANT használatával. Ez a példa a sémát public használja; ha másik sémát ad ki, cserélje le public a séma nevét:

-- Allow authenticator to assume the identity of the user
GRANT "user@databricks.com" TO authenticator;

-- Allow user@databricks.com to access everything in public schema
GRANT USAGE ON SCHEMA public TO "user@databricks.com";
GRANT SELECT, UPDATE, INSERT, DELETE ON ALL TABLES IN SCHEMA public TO "user@databricks.com";
GRANT USAGE ON ALL SEQUENCES IN SCHEMA public TO "user@databricks.com";
GRANT EXECUTE ON ALL FUNCTIONS IN SCHEMA public TO "user@databricks.com";

Ez a példa teljes hozzáférést biztosít az public sémához az user@databricks.com identitás számára. Ezt cserélje le a tényleges Azure Databricks-identitásra, és módosítsa az engedélyeket a követelményeknek megfelelően.

Fontos

Sorszintű biztonság megvalósítása: A fenti engedélyek táblaszintű hozzáférést biztosítanak, de a legtöbb API-használati eset sorszintű korlátozásokat igényel. A több-bérlős alkalmazásokban például a felhasználóknak csak a saját adataikat vagy a szervezetük adatait kell látniuk. A PostgreSQL sorszintű biztonsági (RLS-) házirendjeinek használatával részletes hozzáférés-vezérlést kényszeríthet ki az adatbázis szintjén. Lásd: Sorszintű biztonság implementálása.

Hitelesítés

A Data API eléréséhez meg kell adnia egy Azure Databricks OAuth-jogkivonatot a Authorization HTTP-kérés fejlécében. A hitelesített Azure Databricks-identitásnak rendelkeznie kell egy megfelelő Postgres-szerepkörrel (amelyet az előző lépésekben hoztak létre), amely meghatározza az adatbázis engedélyeit.

OAuth-jogkivonat lekérése

Csatlakozzon a munkaterülethez Azure Databricks-identitásként, amelynek az előző lépésekben létrehozott egy Postgres-szerepkört, és szerezze be az OAuth-jogkivonatot. Útmutatásért tekintse meg a hitelesítést .

Kérés benyújtása

Az OAuth-jogkivonattal és az API URL-címével (amely a Lakebase-alkalmazás API-lapján érhető el) API-kéréseket végezhet curl vagy bármely HTTP-ügyfél használatával. Ne felejtse el hozzáfűzni a séma nevét (például /public) az API URL-címéhez. Az alábbi példák feltételezik, hogy exportálta a DBX_OAUTH_TOKEN és REST_ENDPOINT környezeti változókat.

Íme egy példahívás a várt kimenettel (a minta ügyfelek/projektek/feladatok sémájának használatával):

curl -H "Authorization: Bearer $DBX_OAUTH_TOKEN" \
  "$REST_ENDPOINT/public/clients?select=id,name,projects(id,name)&id=gte.2"

Példa válasz:

[
  { "id": 2, "name": "TechStart Inc", "projects": [{ "id": 3, "name": "Database Migration" }] },
  { "id": 3, "name": "Global Solutions", "projects": [{ "id": 4, "name": "API Integration" }] }
]

Az API-műveletekre vonatkozó további példákért és részletes információkért tekintse meg az API referenciaszakaszát . A lekérdezési paraméterekkel és AZ API-képességekkel kapcsolatos átfogó részletekért tekintse meg a PostgREST API-referenciát. A Lakebase-specifikus kompatibilitási információkért lásd a PostgREST kompatibilitását.

Az API széles körű használata előtt konfigurálja a sorszintű biztonságot az adatok védelme érdekében.

A Data API kezelése

A Data API engedélyezése után a lakebase-alkalmazáson keresztül kezelheti a sémamódosításokat és a biztonsági beállításokat.

Séma gyorsítótár frissítése

Amikor módosítja az adatbázissémát (táblákat, oszlopokat vagy más sémaobjektumokat ad hozzá), frissítenie kell a sémagyorsítótárat. Így a módosítások azonnal elérhetővé válnak a Data API-val.

A sémagyorsítótár frissítése:

  1. Lépjen a Data API-ra a projekt Alkalmazásháttere szakaszában.
  2. Kattintson a Sémagyorsítótár frissítése elemre.

A Data API most már tükrözi a legújabb sémamódosításokat.

Sorszintű biztonság engedélyezése

A Lakebase alkalmazással gyorsan engedélyezheti a sorszintű biztonságot (RLS) az adatbázis tábláihoz. Ha táblák találhatók a sémában, az API lapon megjelenik az Adatvédelem szakasz, amely a következőket jeleníti meg:

  • Az RLS-t engedélyező táblák
  • Az RLS letiltott táblái (figyelmeztetésekkel)
  • Az RLS engedélyezése gomb az összes tábla RLS-ének engedélyezéséhez

Fontos

Az RLS lakebase-alkalmazáson keresztüli engedélyezése bekapcsolja a táblák sorszintű biztonságát. Ha az RLS engedélyezve van, az összes sor alapértelmezés szerint elérhetetlenné válik a felhasználók számára (kivéve a táblatulajdonosokat, a BYPASSRLS attribútummal rendelkező szerepköröket és a felügyelőket – bár a felügyelők nem támogatottak a Lakebase-en). RLS-szabályzatokat kell létrehoznia, hogy a biztonsági követelményeknek megfelelően hozzáférést biztosítson bizonyos sorokhoz. A szabályzatok létrehozásával kapcsolatos információkért tekintse meg a sorszintű biztonságot .

Az RLS engedélyezése a táblákhoz:

  1. Lépjen a projekt Alkalmazás háttere szakaszában a Data API elemre.
  2. Az Adatok védelme szakaszban tekintse át azokat a táblákat, amelyeken nincs engedélyezve az RLS.
  3. Kattintson az RLS engedélyezése elemre az összes tábla sorszintű biztonságának engedélyezéséhez.

Az RLS-t az SQL használatával is engedélyezheti az egyes táblákhoz. Részletekért lásd a sorszintű biztonságot .

Fejlett adat-API beállítások

A Lakebase-alkalmazás API lapján található Speciális beállítások szakasz szabályozza a Data API-végpont biztonságát, teljesítményét és viselkedését.

Közzétett sémák

Alapértelmezett:public

Meghatározza, hogy mely PostgreSQL-sémák legyenek REST API-végpontokként elérhetővé téve. Alapértelmezés szerint csak a public séma érhető el. Ha más sémákat (például, ) használ, apiv1jelölje ki őket a legördülő listából a hozzáadásukhoz.

Megjegyzés:

Az engedélyek az alábbiakra vonatkoznak: A séma hozzáadása elérhetővé teszi a végpontokat, de az API által használt adatbázis-szerepkörnek továbbra is rendelkeznie USAGE kell jogosultságokkal a sémán és SELECT a táblákon lévő jogosultságokkal.

Sorok maximális száma

Alapértelmezett: Üres

Egy adott API-válaszban visszaadandó sorok számának szigorú korlátját kényszeríti ki. Ez megakadályozza a nagy lekérdezések véletlen teljesítménycsökkenését. Az ügyfeleknek lapozási korlátokat kell használniuk az adatok lekéréséhez ezen a küszöbértéken belül. Ez megakadályozza a nagy adatátvitelek váratlan kimenő költségeit is.

CORS-engedélyezett források

Alapértelmezett: Üres (Az összes forrás engedélyezése)

Azt szabályozza, hogy mely webtartományok tudnak adatokat lekérni az API-ból egy böngésző használatával.

  • Üres: Engedélyezi * (bármely tartomány). Hasznos a fejlesztéshez.
  • Termelés: Listázhatja az adott tartományokat (például) annak érdekében, https://myapp.comhogy illetéktelen webhelyek ne kérdezzék le az API-t.

OpenAPI-specifikáció

Alapértelmezett: Letiltva

Azt szabályozza, hogy az automatikusan létrehozott OpenAPI 3 séma elérhető-e a következő helyen /openapi.json: . Ez a séma a táblákat, oszlopokat és REST-végpontokat ismerteti. Ha engedélyezve van, a következőre használhatja:

  • API-dokumentáció létrehozása (Swagger UI, Redoc)
  • Beírt ügyfélkódtárak létrehozása (TypeScript, Python, Go)
  • API importálása a Postmanbe
  • Integráció API-átjárókkal és más OpenAPI-alapú eszközökkel

Kiszolgáló időzítési fejlécek

Alapértelmezett: Letiltva

Engedélyezés esetén a Data API minden válaszban tartalmaz fejléceket Server-Timing. Ezek a fejlécek azt mutatják, hogy a kérés különböző részei mennyi ideig tartottak (például az adatbázis végrehajtási ideje és a belső feldolgozási idő). Ezek az információk a lassú lekérdezések hibakeresésére, a teljesítmény mérésére és az alkalmazás késési problémáinak elhárítására használhatók.

Megjegyzés:

Miután módosította a speciális beállításokat, a Mentés gombra kattintva alkalmazhatja őket.

Sorszintű biztonság

A sorszintű biztonsági (RLS) szabályzatok részletes hozzáférés-vezérlést biztosítanak, mivel korlátozzák, hogy a felhasználók mely sorokhoz férhetnek hozzá egy táblában.

Az RLS működése a Data API-val: Amikor egy felhasználó API-kérelmet küld, a szerepkör átvállalja a authenticator felhasználó identitását. Az adott felhasználó szerepköréhez definiált RLS-szabályzatokat a PostgreSQL automatikusan kikényszeríti, és szűri az általuk elérhető adatokat. Ez az adatbázis szintjén történik, így akkor is, ha az alkalmazáskód megpróbálja lekérdezni az összes sort, az adatbázis csak azokat a sorokat adja vissza, amelyek megtekintésére a felhasználó jogosult. Ez részletes védelmet nyújt anélkül, hogy szűrőlogikát kellene használnia az alkalmazáskódban.

Miért kritikus az RLS az API-k számára? A közvetlen adatbázis-kapcsolatoktól eltérően, ahol ön szabályozza a kapcsolati környezetet, a HTTP API-k egyetlen végponton keresztül teszik elérhetővé az adatbázist több felhasználó számára. A táblaszintű engedélyek önmagukban azt jelentik, hogy ha egy felhasználó hozzáfér a clients táblához, akkor az összes ügyfélrekordhoz hozzáférhet, hacsak nem valósít meg szűrést. Az RLS-szabályzatok biztosítják, hogy minden felhasználó automatikusan csak a jogosult adatait lássa.

Az RLS elengedhetetlen a következő célokhoz:

  • Több-bérlőjű alkalmazások: Az adatok izolációja különböző ügyfelek vagy szervezetek között
  • Felhasználó tulajdonában lévő adatok: Győződjön meg arról, hogy a felhasználók csak a saját rekordjaikhoz férnek hozzá
  • Csoportalapú hozzáférés: A csoporttagok vagy adott csoportok láthatóságának korlátozása
  • Megfelelőségi követelmények: Adathozzáférési korlátozások kényszerítése az adatbázis szintjén

RLS engedélyezése

Az RLS-t a Lakebase alkalmazáson keresztül vagy SQL-utasítások használatával engedélyezheti. A Lakebase-alkalmazás használatára vonatkozó utasításokért lásd: Sorszintű biztonság engedélyezése.

Figyelmeztetés

Ha az RLS-t nem engedélyező táblák vannak engedélyezve, a Lakebase-alkalmazás API-lapján megjelenik egy figyelmeztetés, amely szerint a hitelesített felhasználók megtekinthetik a táblák összes sorát. A Data API közvetlenül kommunikál a Postgres-sémával, és mivel az API az interneten keresztül érhető el, elengedhetetlen, hogy az adatbázis szintjén a PostgreSQL sorszintű biztonságával kényszerítse ki a biztonságot.

Az RLS SQL-sel való engedélyezéséhez futtassa a következő parancsot:

ALTER TABLE clients ENABLE ROW LEVEL SECURITY;

RLS-szabályzatok létrehozása

Miután engedélyezte az RLS-t egy táblán, hozzáférési szabályokat meghatározó szabályzatokat kell létrehoznia. Szabályzatok nélkül a felhasználók nem férhetnek hozzá egyetlen sorhoz sem (alapértelmezés szerint minden sor rejtett).

Szabályzatok működése: Ha az RLS engedélyezve van egy táblában, a felhasználók csak olyan sorokat láthatnak, amelyek megfelelnek legalább egy szabályzatnak. Az összes többi sor ki van szűrve. A táblatulajdonosok, az BYPASSRLS attribútummal rendelkező szerepkörök és a felügyelők megkerülhetik a sorbiztonsági rendszert (bár a felügyelők nem támogatottak a Lakebase-en).

Megjegyzés:

A Lakebase-ben current_user a hitelesített felhasználó e-mail-címét adja vissza (például user@databricks.com). Használja ezt az RLS-szabályzatokban annak azonosításához, hogy melyik felhasználó küldi el a kérést.

Alapszintű szabályzatszintaxis:

CREATE POLICY policy_name ON table_name
  [TO role_name]
  USING (condition);
  • policy_name: A szabályzat leíró neve
  • table_name: A szabályzatot alkalmazni kívánt tábla
  • TO role_name: Nem kötelező. A szabályzat szerepkörét adja meg. Hagyja ki ezt a záradékot, hogy a szabályzatot az összes szerepkörre alkalmazza.
  • USING (condition): Az a feltétel, amely meghatározza, hogy mely sorok láthatók

RLS-oktatóanyag

Az alábbi oktatóanyag a dokumentáció mintasémáját (ügyfelek, projektek, feladattáblák) használja a sorszintű biztonság implementálásának bemutatásához.

Forgatókönyv: Több felhasználóval rendelkezik, akiknek csak a hozzájuk rendelt ügyfeleket és a kapcsolódó projekteket kell látniuk. A hozzáférés korlátozása a következő módon:

  • alice@databricks.com csak az 1. és 2. azonosítójú ügyfeleket tekintheti meg
  • bob@databricks.com csak a 2. és 3. azonosítójú ügyfeleket tekintheti meg

1. lépés: Az RLS engedélyezése az ügyfelek tábláján

ALTER TABLE clients ENABLE ROW LEVEL SECURITY;

2. lépés: Szabályzat létrehozása Alice számára

CREATE POLICY alice_clients ON clients
  TO "alice@databricks.com"
  USING (id IN (1, 2));

3. lépés: Szabályzat létrehozása Bob számára

CREATE POLICY bob_clients ON clients
  TO "bob@databricks.com"
  USING (id IN (2, 3));

4. lépés: A szabályzatok tesztelése

Amikor Alice API-kérést küld:

# Alice's token in the Authorization header
curl -H "Authorization: Bearer $ALICE_TOKEN" \
  "$REST_ENDPOINT/public/clients?select=id,name"

Válasz (Alice csak az 1. és a 2. ügyfelet látja):

[
  { "id": 1, "name": "Acme Corp" },
  { "id": 2, "name": "TechStart Inc" }
]

Amikor Bob API-kérést küld:

# Bob's token in the Authorization header
curl -H "Authorization: Bearer $BOB_TOKEN" \
  "$REST_ENDPOINT/public/clients?select=id,name"

Válasz (Bob csak a 2. és a 3. ügyfelet látja):

[
  { "id": 2, "name": "TechStart Inc" },
  { "id": 3, "name": "Global Solutions" }
]

Gyakori RLS-minták

Ezek a minták a Data API tipikus biztonsági követelményeit fedik le:

Felhasználó tulajdonjoga – Sorok korlátozása a hitelesített felhasználóra:

CREATE POLICY user_owned_data ON tasks
  USING (assigned_to = current_user);

Bérlői elkülönítés – Korlátozza a hozzáférést a felhasználó szervezetére:

CREATE POLICY tenant_data ON clients
  USING (tenant_id = (
    SELECT tenant_id
    FROM user_tenants
    WHERE user_email = current_user
  ));

Csapattagság – Sorok korlátozása a felhasználó csapataira:

CREATE POLICY team_projects ON projects
  USING (client_id IN (
    SELECT client_id
    FROM team_clients
    WHERE team_id IN (
      SELECT team_id
      FROM user_teams
      WHERE user_email = current_user
    )
  ));

Szerepköralapú hozzáférés – A szerepkör-tagság alapján korlátozza a sorokat:

CREATE POLICY manager_access ON tasks
  USING (
    status = 'pending' OR
    pg_has_role(current_user, 'managers', 'member')
  );

Írásvédett az egyes szerepkörök számára – Különböző szabályzatok különböző műveletekhez:

-- Allow all users to read their assigned tasks
CREATE POLICY read_assigned_tasks ON tasks
  FOR SELECT
  USING (assigned_to = current_user);

-- Only managers can update tasks
CREATE POLICY update_tasks ON tasks
  FOR UPDATE
  TO "managers"
  USING (true);

További erőforrások

Az RLS implementálásával kapcsolatos átfogó információkért, beleértve a szabályzattípusokat, a biztonsági ajánlott eljárásokat és a speciális mintákat, tekintse meg a PostgreSQL sorbiztonsági szabályzatainak dokumentációját.

Az engedélyekkel kapcsolatos további információkért lásd: Engedélyek kezelése.

API-referencia

Ez a szakasz feltételezi, hogy elvégezte a beállítási lépéseket, a konfigurált engedélyeket és a sorszintű biztonságot. A következő szakaszok referenciainformációkat tartalmaznak a Data API használatához, beleértve a gyakori műveleteket, a speciális funkciókat, a biztonsági szempontokat és a kompatibilitási részleteket.

Alapműveletek

Rekordok lekérdezése

Rekordok lekérése egy táblából HTTP GEThasználatával:

curl -H "Authorization: Bearer $DBX_OAUTH_TOKEN" \
  "$REST_ENDPOINT/public/clients"

Példa válasz:

[
  { "id": 1, "name": "Acme Corp", "email": "contact@acme.com", "company": "Acme Corporation", "phone": "+1-555-0101" },
  {
    "id": 2,
    "name": "TechStart Inc",
    "email": "hello@techstart.com",
    "company": "TechStart Inc",
    "phone": "+1-555-0102"
  }
]

Szűrés eredményei

Lekérdezési paraméterekkel szűrheti az eredményeket. Ez a példa a 2-nél nagyobb vagy azzal egyenlő ügyfeleket id kéri le:

curl -H "Authorization: Bearer $DBX_OAUTH_TOKEN" \
  "$REST_ENDPOINT/public/clients?id=gte.2"

Példa válasz:

[
  { "id": 2, "name": "TechStart Inc", "email": "hello@techstart.com" },
  { "id": 3, "name": "Global Solutions", "email": "info@globalsolutions.com" }
]

Adott oszlopok kijelölése és táblák illesztése

A paraméter használatával select lekérhet bizonyos oszlopokat, és összekapcsolhatja a kapcsolódó táblákat:

curl -H "Authorization: Bearer $DBX_OAUTH_TOKEN" \
  "$REST_ENDPOINT/public/clients?select=id,name,projects(id,name)&id=gte.2"

Példa válasz:

[
  { "id": 2, "name": "TechStart Inc", "projects": [{ "id": 3, "name": "Database Migration" }] },
  { "id": 3, "name": "Global Solutions", "projects": [{ "id": 4, "name": "API Integration" }] }
]

Rekordok beszúrása

Új rekordok létrehozása a HTTP POST használatával:

curl -X POST \
  -H "Authorization: Bearer $DBX_OAUTH_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "New Client",
    "email": "newclient@example.com",
    "company": "New Company Inc",
    "phone": "+1-555-0104"
  }' \
  "$REST_ENDPOINT/public/clients"

Update típusú rekordok

Meglévő rekordok frissítése HTTP PATCH használatával:

curl -X PATCH \
  -H "Authorization: Bearer $DBX_OAUTH_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"phone": "+1-555-0199"}' \
  "$REST_ENDPOINT/public/clients?id=eq.1"

Rekordok törlése

Rekordok törlése HTTP DELETE használatával:

curl -X DELETE \
  -H "Authorization: Bearer $DBX_OAUTH_TOKEN" \
  "$REST_ENDPOINT/public/clients?id=eq.5"

Speciális funkciók

Oldalszámozás

A visszaadott limit rekordok számának és offset paramétereinek szabályozása:

curl -H "Authorization: Bearer $DBX_OAUTH_TOKEN" \
  "$REST_ENDPOINT/public/tasks?limit=10&offset=0"

Rendezés

Az eredmények rendezése a order paraméterrel:

curl -H "Authorization: Bearer $DBX_OAUTH_TOKEN" \
  "$REST_ENDPOINT/public/tasks?order=due_date.desc"

Összetett szűrés

Több szűrőfeltétel kombinálása:

curl -H "Authorization: Bearer $DBX_OAUTH_TOKEN" \
  "$REST_ENDPOINT/public/tasks?status=eq.in_progress&priority=eq.high"

Gyakori szűrőoperátorok:

  • eq -Egyenlő
  • gte - nagyobb vagy egyenlő
  • lte - kisebb vagy egyenlő
  • neq - nem egyenlő
  • like - mintaegyezés
  • in - megfelel a listában szereplő bármely értéknek

A támogatott lekérdezési paraméterekről és API-funkciókról a PostgREST API-referencia nyújt további információt. A Lakebase-specifikus kompatibilitási információkért lásd a PostgREST kompatibilitását.

Funkciókompatibilitási referencia

Ez a szakasz azokat a PostgREST-funkciókat sorolja fel, amelyek eltérő viselkedésűek, vagy amelyek nem támogatottak a Lakebase Data API-ban.

Hitelesítés és engedélyezés

Tulajdonság Státusz Részletek
JWT-konfiguráció Nem alkalmazható A Lakebase Data API JWT-hitelesítés helyett Azure Databricks OAuth-jogkivonatokat használ. JWT-specifikus konfigurációs beállítások (egyéni titkos kódok, RS256-kulcsok, célközönség érvényesítése) nem érhetők el.

Erőforrás-beágyazás

Tulajdonság Státusz Részletek
Számított kapcsolatok Nem támogatott Az adatbázisfüggvények által definiált egyéni kapcsolatok, amelyek SETOF-t vagy egyetlen rekordot adnak vissza, nem támogatottak. Csak idegenkulcs-kapcsolatok ágyazhatók be.
Belső illesztés beágyazása (!inner tipp) Nem támogatott Nem támogatott az a !inner funkció, amely a bal illesztéseket belső illesztésekké alakítja a szülősorok gyermekadatok alapján történő szűréséhez. Példa: ?select=*,clients!inner(*)&clients.id=eq.1

Válaszformátumok

Tulajdonság Státusz Részletek
Egyéni médiatípus-kezelők Nem támogatott A PostgreSQL-aggregátumokon keresztüli egyéni kimeneti formátumok (bináris formátumok, XML, protokollpufferek) nem támogatottak.
Eltávolított nullértékek Nem támogatott A nulls=stripped JSON-válaszokból null mezőket eltávolító médiatípus paraméter nem támogatott. Példa: Accept: application/vnd.pgrst.object+json;nulls=stripped
PostGIS GeoJSON Részben támogatott A PostGIS geometriai oszlopai lekérdezhetők, de a fejlécen keresztüli Accept: application/geo+json automatikus GeoJSON-formázás nem érhető el.

Lapozás és számolás

Tulajdonság Státusz Részletek
Tervezett darabszám Nem támogatott Az a beállítás, amely a PostgreSQL lekérdezési terv készítőjét használja az eredmények számának becsléséhez, nem támogatott. A Prefer: count=exact használható helyette.
Becsült szám Nem támogatott A Prefer: count=estimated PostgreSQL-statisztikákat hozzávetőleges számokhoz használó beállítás nem támogatott. A Prefer: count=exact használható helyette.

Kérési beállítások

Tulajdonság Státusz Részletek
Időzóna-preferencia Részben támogatott Az időzónák kezelése létezik, de a Prefer: timezone=America/Los_Angeles kiszolgáló időzónájának felülbírálására szolgáló fejléc nem támogatott. Konfigurálja a kiszolgáló időzónát, vagy használjon adatbázisszintű időzónfüggvényeket.
Tranzakcióvezérlés Nem támogatott A tranzakcióvezérlés Prefer: tx=commit és Prefer: tx=rollback fejlécek nem támogatott.
Beállításkezelési módok Nem támogatott Az Prefer: handling=strict érvénytelen beállítások kezelésének szabályozására szolgáló beállítások és Prefer: handling=lenient beállítások nem támogatottak.

Observability

A Lakebase Data API saját megfigyelhetőségi funkciókat valósít meg. A következő PostgREST megfigyelhetőségi funkciók nem támogatottak:

Tulajdonság Státusz Részletek
Lekérdezéstervek expozíciója Nem támogatott A Accept: application/vnd.pgrst.plan+json PostgreSQL-kimenetet EXPLAIN a teljesítményelemzéshez elérhetővé tevő fejléc nem támogatott.
Server-Timing fejléc Nem támogatott A kérések időzítésének lebontását biztosító Server-Timing fejléc nem támogatott. A Lakebase saját megfigyelhetőségi funkciókat valósít meg.
Nyomkövetési fejléc továbbítása Nem támogatott Az X-Request-Id és az egyéni nyomkövetési fejléc propagálása nem támogatott az elosztott nyomkövetéshez. A Lakebase saját megfigyelhetőségi funkciókat valósít meg.

Speciális konfiguráció

Tulajdonság Státusz Részletek
Alkalmazásbeállítások (GUCs) Nem támogatott Az egyéni konfigurációs értékek továbbítása az adatbázisfüggvények számára a PostgreSQL-tartományvezérlőkön keresztül nem támogatott.
Kérés előtti függvény Nem támogatott A db-pre-request konfiguráció, amely lehetővé teszi egy adatbázisfüggvény futtatását minden kérés előtt, nem támogatott.

A PostgREST funkcióival kapcsolatos további információkért tekintse meg a PostgREST dokumentációját.

Biztonsági szempontok

A Data API több szinten kényszeríti ki az adatbázis biztonsági modelljét:

  • Hitelesítés: Minden kéréshez érvényes OAuth-jogkivonat-hitelesítés szükséges
  • Szerepköralapú hozzáférés: Adatbázisszintű engedélyek szabályozzák, hogy mely táblákhoz és műveletekhez férhetnek hozzá a felhasználók
  • Sorszintű biztonság: Az RLS-szabályzatok részletes hozzáférés-vezérlést kényszerítenek ki, amely korlátozza, hogy a felhasználók mely sorokat láthatják vagy módosíthatják
  • Felhasználói környezet: Az API feltételezi a hitelesített felhasználó identitását, biztosítva, hogy az adatbázis engedélyei és szabályzatai megfelelően legyenek alkalmazva

Éles üzemelő példányok esetén:

  1. Sorszintű biztonság megvalósítása: RLS-szabályzatok használatával korlátozza az adathozzáférést a sor szintjén. Ez különösen fontos a több-bérlős alkalmazások és a felhasználói tulajdonú adatok esetében. Lásd sorszintű biztonság.
  2. Minimális engedélyek megadása: Csak azoknak az engedélyeknek a megadása, amelyekre a felhasználóknak szükségük van (SELECT, INSERT, UPDATE, ) DELETEadott táblákra a széles körű hozzáférés biztosítása helyett.
  3. Alkalmazásonként külön szerepkörök használata: Dedikált szerepkörök létrehozása különböző alkalmazásokhoz vagy szolgáltatásokhoz ahelyett, hogy egyetlen szerepkört osztanának meg.
  4. Hozzáférés rendszeres naplózása: Rendszeresen tekintse át a megadott engedélyeket és RLS-szabályzatokat, hogy azok megfeleljenek a biztonsági követelményeknek.

A szerepkörök és engedélyek kezelésével kapcsolatos információkért lásd:

  • Last updated on