RLS Concept
Memahami Row Level Security sebagai aturan database yang membatasi row berdasarkan identity user, bukan sekadar filter UI.
Tujuan belajar
- Menjelaskan RLS sebagai database-level authorization
- Membaca policy user-owned row yang memakai auth.uid()
- Membedakan SELECT using dari INSERT with check
- Menjelaskan mengapa filter client tidak cukup untuk melindungi data
Isi lesson
6 blok- 1.RLS adalah penjaga di dekat row, bukan di dekat tombolBelum selesaiWajib
- 2.Policy untuk catatan milik learner sendiriBelum selesaiWajib
- 3.Coding practiceBelum selesaiWajib
- 4.Cek pemahamanBelum selesaiWajib
- 5.RLS aktif tanpa policy juga bukan aplikasi yang selesaiBelum selesaiWajib
- 6.RingkasanBelum selesaiWajib
RLS adalah penjaga di dekat row, bukan di dekat tombol
WajibBayangkan tabel learning_notes berisi catatan setiap learner. Menyembunyikan tombol atau menambahkan filter user_id di Client Component tidak menghentikan request yang dimodifikasi. RLS menempatkan aturan di Postgres: untuk setiap akses, database mengecek apakah identity pada request memang memiliki hak untuk membaca atau mengubah row tersebut.
Pada tabel di schema yang terekspos seperti public, RLS perlu diaktifkan dan policy perlu ditulis. Policy user-owned yang sederhana biasanya membandingkan auth.uid() dengan kolom user_id. Ini adalah defense in depth: UI, route check, service layer, dan database masing-masing punya tanggung jawab, sehingga satu kesalahan di UI tidak otomatis membuka semua row.
Bagian ini memengaruhi progres lesson.
Policy untuk catatan milik learner sendiri
Wajibalter table public.learning_notes enable row level security;
create policy "Learners can read their own notes"
on public.learning_notes
for select
to authenticated
using ((select auth.uid()) = user_id);
create policy "Learners can create their own notes"
on public.learning_notes
for insert
to authenticated
with check ((select auth.uid()) = user_id);Policy SELECT memakai using untuk menentukan row yang terlihat. Policy INSERT memakai with check untuk memastikan row baru membawa user_id yang sama dengan identity saat ini. Pada update, policy biasanya membutuhkan using untuk row lama dan with check untuk row hasil perubahan. RLS tidak perlu dijelaskan sebagai SQL hafalan; bacalah selalu sebagai pertanyaan: siapa boleh melakukan operasi apa pada row mana?
Bagian ini memengaruhi progres lesson.
Coding practice
WajibDibuka di workspace khususModel user-owned RLS policy
Susun policy reading map untuk data learning note agar operasi select dan insert hanya berlaku untuk row milik identity saat ini.
Tujuan awal: Fokus di tab TSX.
Practice ini dibuka di workspace khusus. Buka practice untuk memakai editor, preview, dan cek otomatis.
Tombol selesai aktif setelah semua validasi wajib lolos.
Cek pemahaman
WajibJawab duluCek pemahaman singkat
Mengapa policy INSERT user-owned memakai with check yang membandingkan auth.uid() dan user_id?
Progres lesson naik setelah jawaban benar.
Kesalahan umum
WajibRLS aktif tanpa policy juga bukan aplikasi yang selesai
Saat RLS aktif pada tabel terekspos, publishable key tidak dapat mengakses data sampai policy mengizinkannya. Jangan kemudian mematikan RLS hanya agar query cepat berhasil. Baca pesan error, pastikan request memiliki auth context, lalu tulis policy paling sempit yang memenuhi kebutuhan feature. Service role key dapat melewati RLS dan bukan solusi untuk Client Component.
Bagian ini memengaruhi progres lesson.
Ringkasan
Wajib- RLS menerapkan authorization pada database untuk setiap akses row.
- Policy user-owned umumnya membandingkan auth.uid() dengan user_id.
- using menentukan row yang boleh diakses, sedangkan with check memeriksa row baru atau hasil update.
- Filter UI dan route redirect tidak menggantikan policy database.
- Berikutnya, kamu akan mengorganisasi query ke service layer agar aturan akses tidak tersebar di component.
Bagian ini memengaruhi progres lesson.
Langkah berikutnya
Selesaikan bagian penting lesson ini
Lanjutkan blok wajib berikutnya: RLS adalah penjaga di dekat row, bukan di dekat tombol.