Supabase bilan ishlaganda ko'pchilik birinchi marta bir narsadan cho'chiydi: ma'lumotlar bazasiga murojaat qiladigan kalit brauzer kodida ko'rinib turadi. Bu xato emas, shunday mo'ljallangan. Savol shu: u holda bazani kim himoya qiladi?
Javob: Row Level Security (RLS) — PostgreSQL'ning yozuv darajasidagi himoyasi. Kalit faqat "kim so'rayapti"ni aniqlaydi, nimaga ruxsat borligini esa siyosatlar hal qiladi.
Asosiy tamoyil
Publishable (anon) kalit ochiq bo'lishi mumkin, chunki RLS yoqilgan jadvalda siyosat ruxsat bermagan hech narsa ishlamaydi. Aksincha, service_role kaliti RLS'ni chetlab o'tadi, shuning uchun u hech qachon brauzerga, ochiq omborga yoki mijoz kodiga tushmasligi kerak. Uni faqat serverda ishlating.
Oddiy misol: shaxsiy yozuvlar
Faraz qiling, har bir foydalanuvchi faqat o'z topshiriqlarini ko'rishi va o'zgartirishi kerak.
alter table public.todos enable row level security;create policy "Own todos: read" on public.todos for select to authenticated using (auth.uid() = user_id);
create policy "Own todos: write" on public.todos for all to authenticated using (auth.uid() = user_id) with check (auth.uid() = user_id); ~~~
Bu yerda using — mavjud qatorlarni ko'rish/o'zgartirish sharti, with check esa yangi yoki o'zgargan qator qoidaga mos kelishini tekshiradi. Ikkalasini ham yozish insert va update orqali boshqa odamning nomiga yozuv yaratishning oldini oladi.
Rollar: admin misoli
Admin huquqini jadvaldan o'qib tekshirish yaxshi usul. Buning uchun xavfsiz yordamchi funksiya yoziladi va siyosatlarda ishlatiladi.
create function public.has_role(_user_id uuid, _role app_role)
returns boolean language sql stable security definer
set search_path = public
as $$ select exists (
select 1 from public.user_roles
where user_id = _user_id and role = _role) $$;Muhim detal: rolni foydalanuvchi o'zi o'zgartira oladigan joyda (masalan, tahrirlanadigan profil maydonida) saqlamang. Rollar faqat serverdan yoki admin tomonidan boshqarilsin.
Eng ko'p uchraydigan xatolar
- Jadval yaratib, RLS'ni yoqishni unutish. Bunda jadval ruxsat berilgan rollar uchun to'liq ochiq bo'lishi mumkin.
- Siyosatni juda keng yozish, masalan using (true), va uni vaqtinchalik deb unutish.
- View'lar va security definer funksiyalarni e'tiborsiz qoldirish: ular egasining huquqi bilan ishlab, RLS'ni chetlab o'tishi mumkin.
- Storage bucket'lar uchun siyosat yozishni unutish, chunki fayllarning ham o'z qoidalari bor.
Sinab ko'rish
Siyosatni yozish bilan ish tugamaydi. Uni anonim, oddiy foydalanuvchi va admin sifatida alohida sinang: har bir rol nimani o'qiy oladi, nimani yoza oladi? Eng yaxshi usul — bu tekshiruvlarni avtomatik testga aylantirish.
Xulosa
Supabase'da xavfsizlik kalitni yashirishda emas, to'g'ri siyosatlarda. Har bir jadvalda RLS yoqing, minimal huquq bering, service_role'ni serverda saqlang va har bir rolni sinab ko'ring.