Supabase RLS ile Multi-Tenant Yetkilendirme: Doğru ve Hızlı Politikalar

Tenant'ı kullanıcı seçmez

Aynı kullanıcı, aynı oturum, aynı tablo. Biri 1.000 satır sayıyor, öteki 500.000:

1-- authenticated rolü, iki tenant'a üye bir kullanıcının JWT'siyle2select count(*) as tablo from public.contracts;3--  tablo4-- -------5--   10006 7select count(*) as view from public.contracts_ozet;8--   view9-- --------10--  500000

İkinci sorgu, sözleşme tablosunun üstüne kurulmuş sıradan bir view'dan okuyor. Tabloda RLS açık, politika doğru, kullanıcı yalnızca üyesi olduğu iki tenant'ın satırlarını görmeli. View ise politikaya hiç sormuyor, çünkü Postgres onu sahibinin yetkisiyle çalıştırıyor ve sahibi postgres.

Supabase'te multi-tenant bir uygulamada, yani birçok müşterinin (tenant) verisinin aynı tablolarda durduğu bir yapıda, yetkilendirme hataları çoğunlukla böyle sessiz olur. Hata mesajı çıkmaz, log temiz kalır, yalnızca fazladan veri döner. Tersi de var: politika doğrudur ama her satırda bir fonksiyon çağırdığı için liste sayfası bir saniyeyi geçer.

Novadesk CRM'deki rol ayrımı tam bu türden bir problem. Admin her şeyi görür, muhasebeci yalnızca yönettiği şirketleri, sekreter de kişileri ve rezervasyonları yönetir ama finans alanlarını görmez. Böyle bir ayrımı arayüze bırakmak yetmez. Kural veritabanında durmalı ki arayüz atlansa bile geçerli olsun. Satırın kime ait olduğunu sorguyu kimin yaptığıyla karşılaştırmak, tenant izolasyonuyla aynı sorudur.

Aşağıdaki örneklerin hepsi Docker'daki düz bir Postgres 17'de çalıştı, çıktılar oradan.

Tenant kimliği nereden gelir

Bir RLS politikası iki değeri karşılaştırır: satırdaki tenant_id ile isteği yapanın hangi tenant'lara ait olduğu. Birincisi tabloda durur. İkincisi için Supabase'te üç kaynak var ve aralarındaki fark doğrudan güvenlik farkı.

İlk satırı hemen eleyin. user_metadata kayıt formundaki ad soyad gibi bilgiler için var ve oturum açmış kullanıcı onu istemciden değiştirebilir. Politikaya auth.jwt() -> 'user_metadata' ->> 'tenant_id' yazmak, kullanıcıya hangi tenant'ın verisini göreceğini seçme hakkı vermektir. Supabase belgeleri bu konuda açıkça uyarıyor, Database Advisor'da da bunu yakalayan ayrı bir kural var (rls_references_user_metadata).

Custom access token hook ile claim eklemek

Custom access token hook, Supabase Auth'un bir access token imzalamadan hemen önce çağırdığı bir Postgres fonksiyonu. Girişte de token yenilemede de çalışır. Fonksiyon claims nesnesini alır, değiştirip geri verir. Aşağıdaki sürüm kullanıcının üyeliklerini app_metadata.tenant_ids dizisine yazıyor:

1create or replace function public.custom_access_token_hook(event jsonb)2returns jsonb3language plpgsql4stable5set search_path = ''6as $$7declare8  claims     jsonb := event -> 'claims';9  tenant_ids jsonb;10begin11  select coalesce(jsonb_agg(m.tenant_id order by m.tenant_id), '[]'::jsonb)12    into tenant_ids13    from public.memberships m14   where m.user_id = (event ->> 'user_id')::uuid;15 16  if jsonb_typeof(claims -> 'app_metadata') is null then17    claims := jsonb_set(claims, '{app_metadata}', '{}');18  end if;19  claims := jsonb_set(claims, '{app_metadata,tenant_ids}', tenant_ids);20 21  return jsonb_set(event, '{claims}', claims);22end;23$$;24 25grant usage on schema public to supabase_auth_admin;26grant execute on function public.custom_access_token_hook to supabase_auth_admin;27revoke execute on function public.custom_access_token_hook from authenticated, anon, public;28grant select on public.memberships to supabase_auth_admin;29create policy memberships_auth_admin on public.memberships30  for select to supabase_auth_admin using (true);

Hook supabase_auth_admin rolüyle çalıştığı için bu role üyelik tablosunu okuma izni ve ona özel bir politika gerekiyor. authenticated ve anon rollerinden execute yetkisini geri almayı atlamayın. Panelde Authentication altındaki Hooks bölümünden fonksiyonu seçince devreye girer. Fonksiyonu elle, Auth sunucusunun göndereceği türden bir olayla çağırınca dönen claim'ler şöyle:

1{2    "sub": "11111111-0000-0000-0000-000000000001",3    "role": "authenticated",4    "app_metadata": {5        "provider": "email",6        "tenant_ids": [7            "00000000-0000-0000-0000-000000000001",8            "00000000-0000-0000-0000-000000000002"9        ]10    }11}

Gerçek olayda Auth'un zorunlu saydığı claim'lerin hepsi (iss, aud, exp, iat, sub, role, aal, session_id, email, phone, is_anonymous) zaten gelir. Hook bunlardan birini silerse token verilmez, bu yüzden yalnızca ekleme yapın. Ortaya çıkan token'ı JWT çözücüde açıp claim'leri görebilirsiniz. İmzayı doğrulamadan çözmenin neden yetkilendirme sayılmadığını JWT doğrulama hataları yazısında anlatmıştım.

Token yenilenene kadar eski kalır

JWT'ye yazılan her şey imzalandığı anın fotoğrafıdır. Kullanıcıyı bir tenant'tan çıkardığınızda token'daki dizi değişmez. Aşağıda aynı token'la, üyelik silindikten sonra iki ayrı politika deneniyor:

1begin;2drop policy contracts_select on public.contracts;3create policy contracts_select on public.contracts for select to authenticated4  using (tenant_id = any (array(5    select jsonb_array_elements_text(auth.jwt() -> 'app_metadata' -> 'tenant_ids')::uuid6  )));7-- :'jwt' iki tenant içeren app_metadata.tenant_ids taşıyan claim'ler8select set_config('request.jwt.claims', :'jwt', true) \gset9 10set local role authenticated;11select count(*) as once from public.contracts;        -- 100012reset role;13 14-- kullanıcı 2 numaralı tenant'tan çıkarıldı, token henüz yenilenmedi15delete from public.memberships16 where tenant_id = '00000000-0000-0000-0000-000000000002'17   and user_id   = '11111111-0000-0000-0000-000000000001';18 19set local role authenticated;20select count(*) as jwt_ile from public.contracts;     -- 100021reset role;22 23drop policy contracts_select on public.contracts;24create policy contracts_select on public.contracts for select to authenticated25  using (tenant_id = any (array(select private.my_tenant_ids())));26set local role authenticated;27select count(*) as tablo_ile from public.contracts;   -- 50028rollback;

JWT'ye bakan politika, silinen tenant'ın 500 satırını göstermeye devam ediyor. Bu gecikmenin üst sınırı access token'ın ömrü. Supabase'te varsayılan bir saat ve belgeler beş dakikanın altına inmemeyi öneriyor, çünkü yenileme yükü artıyor ve saat kayması kaynaklı hatalar başlıyor. Rolü değişen kullanıcı refreshSession() çağırırsa yeni claim'leri hemen alır, ama tenant'tan çıkarılan kullanıcının bunu yapmak için hiçbir nedeni yok.

Ben şöyle ayırıyorum. Yetkiyi daraltan bir değişiklik (tenant'tan çıkarma, rol düşürme) anında geçerli olmalıysa kaynak tablo olur. JWT claim'i menüde hangi tenant'ların listeleneceğini göstermek ya da seçili tenant'ı hatırlamak için yeterli. Sözleşme tutarı ve TC kimlik numarası tutan bir CRM'de bir saatlik pencere kabul edilecek bir risk değil.

Politika satır başına mı, sorgu başına mı çalışıyor

Tabloyu kaynak seçince ilk itiraz performanstan gelir: her sorguda üyelik tablosuna gitmek pahalı değil mi? Doğru yazılırsa değil. Bunu görmek için Supabase'in kendisine gerek yok. Docker'da düz bir postgres:17 konteyneri, birkaç rol ve auth şemasının küçük bir taklidi yetiyor (Docker temelleri yazısındaki komutlar burada da geçerli):

1create role anon nologin;2create role authenticated nologin;3create role service_role nologin bypassrls;4create role supabase_auth_admin nologin;5 6create schema auth;7create table auth.users (8  id uuid primary key,9  raw_app_meta_data  jsonb not null default '{}',10  raw_user_meta_data jsonb not null default '{}'11);12 13-- supabase/auth deposundaki tanımın aynısı14create function auth.uid() returns uuid language sql stable as $$15  select nullif(16    coalesce(17      current_setting('request.jwt.claim.sub', true),18      (current_setting('request.jwt.claims', true)::jsonb ->> 'sub')19    ), ''20  )::uuid21$$;22 23create function auth.jwt() returns jsonb language sql stable as $$24  select coalesce(25    nullif(current_setting('request.jwt.claim', true), ''),26    nullif(current_setting('request.jwt.claims', true), '')27  )::jsonb28$$;29 30grant usage on schema auth to anon, authenticated, service_role;

auth.uid() ve auth.jwt() tanımları supabase/auth deposundaki migration'ların aynısı. PostgREST her istekte rolü authenticated yapar ve JWT claim'lerini request.jwt.claims ayarına yazar. Testte aynısını bir transaction içinde elle yapıyoruz:

1begin;2set local role authenticated;3set local request.jwt.claims to4  '{"sub":"11111111-0000-0000-0000-000000000001","role":"authenticated"}';5select count(*) from public.contracts;6rollback;

Veri seti 1.000 tenant, 5.000 kullanıcı ve 500.000 sözleşmeden oluşuyor, test kullanıcısı da iki tenant'a üye olduğu için 1.000 satır görmeli. Süreler explain analyze çıktısındaki Execution Time değerleri, her sorgu ikinci kez çalıştırılarak alındı.

auth.uid() her satırda yeniden hesaplanıyor

Tenant'ı bir kenara bırakıp önce en basit politikaya bakın: created_by = auth.uid(). created_by sütununda indeks yok. Kısaltılmış planlar:

1-- politika: created_by = auth.uid()2 Aggregate (actual time=221.639..221.639 rows=1 loops=1)3   ->  Seq Scan on contracts (actual time=1.508..221.620 rows=100 loops=1)4         Filter: (created_by = (NULLIF(COALESCE(current_setting('request.jwt.claim.sub'::text, true), ((current_setting('request.jwt.claims'::text, true))::jsonb ->> 'sub'::text)), ''::text))::uuid)5         Rows Removed by Filter: 4999006 Execution Time: 221.654 ms7 8-- politika: created_by = (select auth.uid())9 Aggregate (actual time=16.589..16.590 rows=1 loops=1)10   InitPlan 111     ->  Result (actual time=0.012..0.012 rows=1 loops=1)12   ->  Seq Scan on contracts (actual time=0.224..16.574 rows=100 loops=1)13         Filter: (created_by = (InitPlan 1).col1)14         Rows Removed by Filter: 49990015 Execution Time: 16.622 ms

auth.uid() basit bir SQL fonksiyonu olduğundan planlayıcı onu inline ediyor, yani gövdesini politikanın içine yerleştiriyor. Sonuçta 500.000 satırın her birinde current_setting() çağrılıp JSON baştan parse ediliyor. Parantez içindeki select ise bir InitPlan'a dönüşüyor. Değer sorgu başında bir kez hesaplanıyor, filtre tek bir karşılaştırmaya iniyor ve süre 221 ms'den 16,6 ms'ye düşüyor. Bu numara yalnızca sonucu satıra bağlı olmayan ifadelerde işe yarar: auth.uid(), auth.jwt() ve parametre almayan yardımcı fonksiyonlar.

Üyelik kontrolünün dört yazımı

Asıl politika tenant kontrolü. Üyelik sorgusunu private adlı, Data API'nin erişimine açık olmayan bir şemadaki iki fonksiyona taşıdım:

1create schema private;2grant usage on schema private to authenticated;3 4-- kullanıcı yalnızca kendi üyelik satırlarını görür5create policy memberships_select on public.memberships6  for select to authenticated7  using (user_id = (select auth.uid()));8 9-- satır başına çağrılan üyelik kontrolü10create function private.is_member(t uuid) returns boolean11language plpgsql stable security definer set search_path = '' as $$12begin13  return exists (14    select 1 from public.memberships m15    where m.tenant_id = t and m.user_id = auth.uid()16  );17end $$;18 19-- kullanıcının bütün tenant'ları, sorgu başına bir kez20create function private.my_tenant_ids() returns setof uuid21language sql stable security definer set search_path = '' as $$22  select m.tenant_id from public.memberships m where m.user_id = auth.uid()23$$;24 25revoke execute on all functions in schema private from public;26grant execute on all functions in schema private to authenticated;

Aynı select count(*) from public.contracts sorgusu, dört ayrı politikayla:

İki sonuç dikkat istiyor. İlki satır başına çağrılan fonksiyon: is_member(tenant_id) doğru cevap veriyor ama 500.000 kez çalışıyor ve indeks hiçbir şeyi kurtarmıyor. İkincisi daha şaşırtıcı. tenant_id in (select ...) indeks eklendiğinde bile 16 ms civarında kalıyor. Nedeni planda:

1-- politika: tenant_id in (select private.my_tenant_ids())2 Aggregate (actual time=16.540..16.540 rows=1 loops=1)3   ->  Index Only Scan using contracts_tenant_idx on contracts (actual time=0.043..16.517 rows=1000 loops=1)4         Filter: (ANY (tenant_id = (hashed SubPlan 1).col1))5         Rows Removed by Filter: 4990006         Heap Fetches: 07         SubPlan 18           ->  ProjectSet (actual time=0.037..0.039 rows=2 loops=1)9                 ->  Result (actual time=0.000..0.000 rows=1 loops=1)10 Execution Time: 16.547 ms11 12-- politika: tenant_id = any (array(select private.my_tenant_ids()))13 Aggregate (actual time=0.091..0.091 rows=1 loops=1)14   InitPlan 115     ->  ProjectSet (actual time=0.026..0.027 rows=2 loops=1)16           ->  Result (actual time=0.000..0.000 rows=1 loops=1)17   ->  Index Only Scan using contracts_tenant_idx on contracts (actual time=0.033..0.068 rows=1000 loops=1)18         Index Cond: (tenant_id = ANY ((InitPlan 1).col1))19         Heap Fetches: 020 Execution Time: 0.094 ms

IN alt sorgusu politikanın içinde hashed SubPlan olarak kalıyor. Postgres tenant listesinden bir hash tablosu kuruyor, sonra indeksin 500.000 girdisinin hepsini okuyup her birini o tabloda arıyor. Aynı alt sorguyu politikaya değil doğrudan WHERE içine yazdığımda planlayıcı onu semi-join'e çevirdi ve indeksle 0,2 ms'de bitirdi. Politikadaki alt sorguda bu dönüşüm olmadı. = any(array(select ...)) biçimi ise listeyi InitPlan'da bir diziye topluyor ve diziyi Index Cond olarak indekse veriyor. 1.000 satırı bulmak için 1.000 satır okunuyor.

Supabase'in RLS performans önerileri de aynı yeri gösteriyor: politika sütunlarına indeks, fonksiyonları select ile sarmak ve dizi döndüren fonksiyonlar için team_id = any(array(select user_teams())) kalıbı. Database Advisor sarılmamış auth.uid() çağrılarını auth_rls_initplan kuralıyla işaretliyor.

security definer ve search_path

Üyelik sorgusunu neden bir fonksiyona taşıdık? Çünkü üyelik tablosunun politikası kendi tablosuna bakan bir alt sorguyla yazılırsa Postgres bunu sonsuz döngü sayıyor:

1create policy memberships_select_kotu on public.memberships for select to authenticated2  using (tenant_id in (select tenant_id from public.memberships where user_id = auth.uid()));3 4-- authenticated rolüyle:5select count(*) from public.memberships;6-- ERROR:  infinite recursion detected in policy for relation "memberships"

security definer bir fonksiyon, sahibinin yetkisiyle çalıştığı için üyelik tablosunu RLS'e takılmadan okur ve döngü kırılır. Bedeli şu: fonksiyonun içindeki nitelenmemiş tablo adları çağıranın search_path'ine göre çözülür ve Postgres geçici tabloların şemasına (pg_temp) başka her şeyden önce bakar. search_path sabitlenmeden yazılmış aynı fonksiyonla:

1-- search_path sabitlenmemiş, tablo adı nitelenmemiş2create function private.my_tenant_ids_kotu() returns setof uuid3language sql stable security definer as $$4  select tenant_id from memberships where user_id = auth.uid()5$$;6grant execute on function private.my_tenant_ids_kotu() to authenticated;7 8begin;9drop policy contracts_select on public.contracts;10create policy contracts_select on public.contracts for select to authenticated11  using (tenant_id = any (array(select private.my_tenant_ids_kotu())));12set local role authenticated;13set local request.jwt.claims to '{"sub":"11111111-0000-0000-0000-000000000001","role":"authenticated"}';14select count(*) as once from public.contracts;    -- 100015 16create temp table memberships (tenant_id uuid, user_id uuid);17insert into memberships18  select ('00000000-0000-0000-0000-' || lpad(g::text, 12, '0'))::uuid, auth.uid()19  from generate_series(1, 1000) g;20select count(*) as sonra from public.contracts;   -- 50000021rollback;

Kullanıcı kendi oturumunda memberships adında geçici bir tablo açıp bin tenant'ın kimliğiyle doldurunca fonksiyon gerçeği yerine bu tabloyu okudu ve politika bütün sözleşmeleri açtı. PostgREST üzerinden gelen bir istek tablo oluşturamaz, yani bu Data API'den yapılabilecek bir saldırı değil. Ama veritabanına SQL ile bağlanabilen her rol için açık bir kapı. Çaresi iki adım: set search_path = '' ve her nesneyi şemasıyla yazmak (public.memberships). Advisor bunu function_search_path_mutable kuralıyla yakalıyor. Fonksiyonu Data API'nin erişimine açık bir şemaya koymamak da şart, yoksa herkes onu RPC olarak çağırabilir.

RLS'i sessizce aşan yollar

service_role ve secret anahtarlar

service_role rolü BYPASSRLS özniteliğiyle gelir. Eski JWT tabanlı service_role anahtarı da yeni sb_secret_... anahtarları da bu role bağlanır ve hiçbir politikaya bakmaz. Denemedeki aynı sayım bu rolle 500.000 döndü. Yeni secret anahtarın küçük bir ek koruması var: tarayıcıdan gelen istekleri User-Agent başlığına bakarak 401 ile reddediyor. Sunucu kodundaki en sık hata ise kullanıcı adına yapılan bir isteği kolaylık olsun diye bu anahtarla atmak. Kullanıcı adına yapılan her istek kullanıcının JWT'siyle gitmeli.

Ters yönde bir sürpriz de var. Servis anahtarıyla oluşturulmuş bir istemcide bir kullanıcı oturum açarsa Supabase o kullanıcının politikalarını uygular. Yönetim işleri için ayrı, hiç oturum açılmayan bir istemci tutun.

security_invoker olmayan view'lar

Girişteki fark buradan geliyordu. Postgres'te bir view taban tabloya varsayılan olarak sahibinin yetkileriyle erişir. Supabase'te view'ları çoğunlukla postgres oluşturur, tablonun sahibi de odur ve sahip RLS'ten muaf olduğu için view politikasız çalışır. Postgres 15'ten beri bunu tek bir seçenek düzeltiyor:

1alter view public.contracts_ozet set (security_invoker = true);2 3-- authenticated rolüyle, aynı kullanıcı:4select count(*) as view_invoker from public.contracts_ozet;5--  view_invoker6-- --------------7--          1000

Bir ayrıntıyı kaçırmayın: security_invoker satır güvenliğini geri getirir, sütun gizlemez. Invoker view'ı sorgulayan kullanıcının taban tabloda da yetkisi olmalı, yani o kullanıcı tabloyu doğrudan da okuyabilir. Supabase'te oturum açmış herkes aynı authenticated Postgres rolünü kullandığı için sütun düzeyindeki GRANT'ler sekreteri muhasebeciden ayıramaz. Finans sütunlarını bir uygulama rolünden gizlemek istiyorsanız ben o sütunları ayrı bir tabloya alıp o tabloya üyelikteki rolü denetleyen ayrı bir politika yazmayı tercih ederim. Advisor, security_invoker olmayan view'ları security_definer_view kuralıyla listeliyor.

Tenant'ı denetlemeyen with check

Okuma politikası doğru olsa bile yazma ayrı bir kapıdır. INSERT politikası yalnızca with check alır ve Postgres eklenen her satırı bu ifadeyle sınar. İfadeyi hiç yazmazsanız kapı kapalı kalır, denemede with check içermeyen bir INSERT politikası her eklemeyi reddetti. Tehlike, ifadeyi yazıp tenant'ı denetlememekte:

1-- 1) yalnızca giriş yapılmış mı diye bakan politika2create policy contracts_insert on public.contracts for insert to authenticated3  with check ((select auth.uid()) is not null);4 5insert into public.contracts (tenant_id, company, amount)6values ('00000000-0000-0000-0000-000000000999', 'Başkasının kiracısı', 1);7-- INSERT 0 18 9-- 2) tenant'ı denetleyen politika10drop policy contracts_insert on public.contracts;11create policy contracts_insert on public.contracts for insert to authenticated12  with check (tenant_id = any (array(select private.my_tenant_ids())));13 14insert into public.contracts (tenant_id, company, amount)15values ('00000000-0000-0000-0000-000000000999', 'Başkasının kiracısı', 1);16-- ERROR:  new row violates row-level security policy for table "contracts"

İlk politika yalnızca giriş yapılıp yapılmadığına baktığı için kullanıcı başka bir tenant'a kayıt ekleyebiliyor, ikincisi ise okuma politikasıyla aynı tenant listesini kullanıyor ve satırı reddediyor. UPDATE'te with check yazılmazsa using ifadesi yeni satıra da uygulanır, bu yüzden bir satırı başka tenant'a taşımak engellenir. with check (true) yazarsanız bu koruma gider.

Bir tuzak daha var ve çoğu zaman tenant oluştururken ortaya çıkar. insert ... returning, supabase-js'te de .insert().select(), eklenen satırın SELECT politikasından da geçmesini ister. Yeni tenant'ın henüz üyesi olmadığınız için:

1create policy tenants_insert on public.tenants for insert to authenticated2  with check (true);3create policy tenants_select on public.tenants for select to authenticated4  using (id = any (array(select private.my_tenant_ids())));5 6insert into public.tenants (name) values ('Yeni Ofis');7-- INSERT 0 18 9insert into public.tenants (name) values ('Yeni Ofis') returning id;10-- ERROR:  new row violates row-level security policy for table "tenants"

Kayıt reddedilmedi, döndürülemedi. Postgres bunu sessizce yutmak yerine hata veriyor. Çözüm, üyelik tablosuna "kullanıcı kendini ekleyebilir" diyen bir politika yazmak değil, çünkü o politika herkesin her tenant'a katılmasına izin verir. Tenant'ı ve kurucunun admin üyeliğini aynı transaction'da yazan tek bir fonksiyon daha güvenli.

Storage politikaları

Supabase Storage dosya erişimini storage.objects tablosundaki RLS politikalarıyla yönetir ve politika yoksa hiçbir bucket'a yükleme yapılamaz. Multi-tenant bir yapıda en temiz yol, dosya yolunun ilk klasörünü tenant kimliği yapmak ve politikada o klasörü storage.foldername() ile okumak. Tabloyu ve fonksiyonu Supabase'in tanımına benzer biçimde taklit edip aynı politikaları denedim:

1create policy contracts_files_select on storage.objects2  for select to authenticated3  using (4    bucket_id = 'contracts'5    and (storage.foldername(name))[1] = any (array(select private.my_tenant_ids()::text))6  );7create policy contracts_files_insert on storage.objects8  for insert to authenticated9  with check (10    bucket_id = 'contracts'11    and (storage.foldername(name))[1] = any (array(select private.my_tenant_ids()::text))12  );13 14-- iki dosya var: biri kullanıcının tenant'ında, biri 3 numaralı tenant'ta15select name from storage.objects;16--                            name17-- ----------------------------------------------------------18--  00000000-0000-0000-0000-000000000001/2025/sozlesme-1.pdf19 20insert into storage.objects (bucket_id, name)21values ('contracts', '00000000-0000-0000-0000-000000000003/2025/sahte.pdf');22-- ERROR:  new row violates row-level security policy for table "objects"

Okumada yalnızca kullanıcının tenant'ındaki dosya göründü, başka tenant'ın klasörüne yükleme reddedildi. Üzerine yazmak (upsert) için SELECT ve UPDATE politikaları da gerekir. Storage API'ye servis anahtarıyla gelen istek bu politikaların hepsini atlar. İmzalı URL ise süresi dolana kadar bağlantıyı bilen herkese açıktır. Süreyi kısa tutun.

Politikayı rol değiştirerek test etmek

Yanlış bir politika derleme hatası üretmez, o yüzden test ister. İlke yukarıdaki denemelerle aynı: transaction açın, rolü authenticated yapın, request.jwt.claims ayarına test kullanıcısının claim'lerini yazın, sorguyu çalıştırın ve sonunda rollback ile her şeyi geri alın. Supabase CLI'daki supabase test db komutu supabase/tests/database/ altındaki SQL dosyalarını pgTAP ile çalıştırıyor. Aynı dosya düz Postgres'te pgTAP eklentisiyle de koşuyor:

1-- supabase/tests/database/contracts_rls.test.sql2begin;3select plan(4);4 5set local role authenticated;6set local request.jwt.claims to7  '{"sub":"11111111-0000-0000-0000-000000000001","role":"authenticated"}';8 9select is(10  (select count(*) from public.contracts),11  1000::bigint,12  'kullanıcı yalnızca iki kiracısının sözleşmelerini görür'13);14 15select is_empty(16  $$ select 1 from public.contracts17     where tenant_id = '00000000-0000-0000-0000-000000000003' $$,18  'başka kiracının satırı görünmez'19);20 21select throws_ok(22  $$ insert into public.contracts (tenant_id, company, amount)23     values ('00000000-0000-0000-0000-000000000003', 'Sızma', 1) $$,24  '42501',25  'new row violates row-level security policy for table "contracts"',26  'başka kiracıya kayıt eklenemez'27);28 29select is(30  (select count(*) from public.contracts_ozet),31  1000::bigint,32  'özet view de RLS''e uyar'33);34 35select * from finish();36rollback;

11..42ok 1 - kullanıcı yalnızca iki kiracısının sözleşmelerini görür3ok 2 - başka kiracının satırı görünmez4ok 3 - başka kiracıya kayıt eklenemez5ok 4 - özet view de RLS'e uyar

Her tenant tablosu için en az üç test öneririm: kendi satırlarını görmek, başka tenant'ın satırını görmemek ve başka tenant'a yazamamak. View'lar ve Storage politikaları da aynı listeye girer. Kod incelemesinde gözden kaçan bir security_invoker eksikliği dördüncü testte hemen kırmızı yanar. Gerçek bir Supabase projesinde testi bir de supabase_auth_admin rolüyle hook için yazmak, hook'un yanlış tenant listesi üretmesini erkenden yakalar.

Sonuç

Bir politikayı birleştirmeden önce iki soru sorun. Karşılaştırdığınız değeri kullanıcı yazabiliyor mu? Yazabiliyorsa elinizde bir politika değil, bir rica var. İfade satır başına mı çalışıyor? Öyleyse tablo büyüdükçe sorun da büyüyecek. Birinci sorunun cevabı üyelik tablosu ya da sunucunun yazdığı app_metadata, ikincisininki = any(array(select ...)) ve bir indeks. View'lar, Storage ve servis anahtarı aynı iki kuralın başka kapılardan sınanması. Onları kod incelemesi değil, rolü değiştirip sayıya bakan bir test yakalar.