Supabase RLS politika üretici

Erişim şeklini seç, tablo adını gir: kopyalanabilir RLS politikası ve doğrulama sorgusu al.

Adım 1 / 2

Erişimi nasıl sınırlamak istiyorsun?

Bunu kendi projene mi taşımak istiyorsun?

45 dakikalık keşif görüşmesinde konuşalım.

Görüşme ayarla

Lovable, Bolt ve v0 gibi araçlar bir Supabase tablosu açar, satır seviyesinde erişim kuralını yazmaz. Kurucu RLS'i sonradan açtığında bu sefer uygulama veri okuyamaz, çoğu zaman kapatıp öyle bırakır. Bu araç beş erişim şekli için: satır sahipliği, takım/organizasyon üyeliği, herkese açık okuma, admin kontrolü ve storage bucket, kopyalanabilir SQL politikası üretir.

Her politika Supabase'in kendi dokümanındaki iki kurala uyuyor: auth.uid() çağrısı select içine sarılıyor çünkü Postgres sonucu sorgu başına önbelleğe alıyor, satır satır yeniden çağırmıyor; her politika to authenticated (ya da herkese açık okumada to anon, authenticated) ile sınırlı çünkü rol belirtilmeden yazılan bir politika kayıtsız istekleri de kapsayabilir.

Üretilen SQL bir şablon, veritabanına bağlanmıyor ve şema okumuyor: kendi tablo ve sütun adlarını girip önce staging'de dene. RLS zaten en sık patlayan katman; Lovable ve Bolt ile yapılan uygulamalarda hangi açıkların tekrarlandığını okuyabilirsin. Kritik bulguları kendin kapatamıyorsan yapay zeka projesi tamamlama hizmetimiz devralıyor. Kurulumunu genel olarak kontrol etmek istersen yayına hazırlık kontrolüne bak.

Sık sorulanlar

Bu araç Supabase projeme bağlanıyor mu?

Hayır. Tarayıcında çalışıyor, veritabanına bağlanmıyor, şema okumuyor. Girdiğin tablo ve sütun adlarından SQL üretiyor; üretilen politikayı canlıya almadan staging'de veya SQL editor'de yeni bir oturumda test et.

Neden her koşulda (select auth.uid()) var, sade auth.uid() değil?

Supabase'in kendi performans notuna göre: fonksiyonu select içine sarmak Postgres'e sonucu sorgu başına önbelleğe alma imkanı veriyor, aksi halde fonksiyon her satırda yeniden çağrılıyor.

Politikalarda neden ayrıca auth.uid() IS NOT NULL kontrolü yok?

Her politika to authenticated (ya da herkese açık okumada to anon, authenticated) ile sınırlı. Supabase dokümanı rolü her zaman belirtmeyi öneriyor; rolü belirtmeden yazılan bir politika kayıtsız istekleri de kapsayabilir, biz bunun yerine rolü açıkça yazıyoruz.

Beş erişim şeklinden hangisini seçeceğimi bilmiyorum, ne olur?

Her seçenek kısa bir açıklama içeriyor: satırı kimin görüp değiştirebileceğini anlatıyor. Yanlış seçersen baştan başla düğmesiyle sıfırdan başlarsın, hiçbir cevap kaybolmaz çünkü hiçbir şey kaydedilmiyor.