vibe-coding-college-specs/chapters/07-database-and-backend/07-lesson-database-security-rls/spec.md

مشخصات درس‌نامه: امنیت پایگاه داده با Row Level Security (RLS)

• شناسه در سیلابس: L7.8
• فصل: فصل ۷: داده و بک‌اند (Ch 7)
• نوع محتوا: 📘 درس‌نامه متنی
• زمان تقریبی مطالعه: ۱۲ دقیقه
• پیش‌نیازهای مستقیم: L7.7 (احراز هویت)

---

۱. اهداف یادگیری (Learning Objectives - Bloom's Taxonomy)

دانشجو پس از مطالعهٔ این درس‌نامه باید بتواند:

• درک کند (Understand): سازوکار امنیت در سطح ردیف (Row Level Security - RLS) در پایگاه داده PostgreSQL چیست و چرا به عنوان دیوار آتشین و غیرقابل نفوذ دیتابیس عمل می‌کند.
• تحلیل/ارزیابی کند (Evaluate): خطر هولناک غیرفعال بودن RLS را تحلیل کند و بداند چرا بدون RLS، هر فرد متفرقه‌ای با داشتن کلید عمومی anon key می‌تواند کل داده‌های پروژه را با یک درخواست ساده پاک کند.
• به‌کار ببندد (Apply): قابلیت RLS را روی جداول پروژه محوری (projects و site_settings) در پیشخوان Supabase یا با دستورات SQL فعال سازد.
• به‌کار ببندد (Apply): دو سیاست امنیتی استاندارد را پیاده‌سازی کند: سیاست خواندن عمومی برای همه کاربران (Public Read via SELECT) و سیاست نگارش، ویرایش و حذف منحصراً برای ادمین لاگین‌شده (auth.role() = 'authenticated').
• به‌کار ببندد (Apply): عملکرد قوانین امنیتی را با باز کردن سایت در تب ناشناس (Incognito) و تلاش برای ویرایش غیرمجاز تست و راستی‌آزمایی کند.

---

۲. محدوده و مرزهای محتوا (Scope & Boundaries)

آنچه باید پوشش داده شود (In-Scope):

1. کابوس بزرگ وب بدون RLS:
   • از آنجا که کلید عمومی anon key در کدهای فرانت‌اند مرورگر قرار دارد، اگر RLS فعال نباشد، هر هکر یا کاربری می‌تواند با ابزارهایی مثل Postman یا دستور curl، یک درخواست DELETE به سرور بفرستد و در یک ثانیه تمام کارهای پورتفولیو را پاک کند!
   • دیوار آتشین RLS کاری می‌کند که خود موتور دیتابیس PostgreSQL پیش از اجرای هر عملیاتی بپرسد: «آیا این کاربر اجازه این کار را دارد؟»
2. سازوکار امنیت در سطح ردیف (Row Level Security چیست؟):
   • قوانینی که مستقیماً در لایه عمیق پایگاه داده (نه در فرانت‌اند) تعریف و اعمال می‌شوند.
   • حتی اگر کسی کدهای فرانت‌اند شما را دور بزند، دیتابیس بدون مجوز اجازه عبور نخواهد داد.
3. تعریف سیاست‌های امنیتی (Security Policies) برای پروژه پورتفولیو:
   • سیاست‌های جدول پروژه‌ها (projects):
     • قانون ۱ (خواندن برای عموم آزاد): همه افراد در جهان باید بتوانند نمونه‌کارها را ببینند:

       CREATE POLICY "Public projects are viewable by everyone" 
       ON projects FOR SELECT 
       USING (true);
       

     • قانون ۲ (فقط ادمین لاگین‌شده حق ویرایش دارد): فقط کاربری که با موفقیت در Supabase Auth لاگین کرده اجازه ثبت، ویرایش و حذف دارد:

       CREATE POLICY "Only authenticated admin can insert, update, delete" 
       ON projects FOR ALL 
       TO authenticated 
       USING (true);
       

   • سیاست‌های جدول تنظیمات سئو (site_settings):
     • خواندن تنظیمات برای عموم آزاد (FOR SELECT USING (true)).
     • ویرایش تنظیمات فقط توسط ادمین تاییدشده (FOR UPDATE TO authenticated).
4. اسکریپت کامل فعال‌سازی RLS با SQL:
   • دستورات صریح فعال‌سازی:

     ALTER TABLE projects ENABLE ROW LEVEL SECURITY;
     ALTER TABLE site_settings ENABLE ROW LEVEL SECURITY;
     

5. تست و سنجش امنیت در عمل:
   • باز کردن صفحه اصلی در تب ناشناس مرورگر: همه پروژه‌ها به درستی نمایش داده می‌شوند (تست موفق قانون SELECT).
   • تلاش برای ارسال درخواست ایجاد یا حذف بدون ورود: دریافت خطای قاطع 403 Forbidden / Row Level Security Violation.
6. کال‌اوت‌های Quera:
   • <details class="violet">: چرا امنیت در سطح پایگاه داده (Database-Level Security) هزاران بار نفوذناپذیرتر از چک‌های ظاهری در کدهای جاوااسکریپت است؟
   • <details class="red">: پرچم قرمز مرگبار؛ هرگز پروژه‌ای را در وضعیت «RLS Disabled» روی اینترنت رها نکنید؛ این کار معادل رها کردن گاوصندوق باز در خیابان است!

آنچه نباید وارد آن شویم (Out-of-Scope):

• تعریف رول‌های پیچیده چندسطحی سازمانی (RBAC با چندین سطح دسترسی نظیر سوپرادمین، نویسنده، ویرایشگر).
• تنظیمات فایروال شبکه یا DDoS Protection سرور (فصل ۱۱ امنیت و انتشار).

---

۳. مفاهیم کلیدی و کلمات تخصصی (Key Concepts & Terms)

اصطلاح انگلیسی	معادل فارسی مصوب	توضیح یک‌خطی ساده
Row Level Security (RLS)	امنیت در سطح ردیف	مکانیزم امنیتی در دیتابیس که دسترسی به تک‌تک سطرهای جدول را بر اساس هویت کاربر فیلتر می‌کند
Security Policy	خط‌مشی / سیاست امنیتی	قانون صریحی در دیتابیس که تعیین می‌کند چه کسی حق اجرای SELECT، INSERT، UPDATE یا DELETE را دارد
Authenticated Role	نقش کاربری احراز هویت‌شده	برچسب امنیتی در دیتابیس برای کاربرانی که لاگین موفق با نشست فعال داشته‌اند
Database Firewall	دیوار آتشین پایگاه داده	سپر دفاعی مستقر در هسته دیتابیس برای رد خودکار درخواست‌های غیرمجاز
403 Forbidden	خطای دسترسی غیرمجاز	کد وضعیت وب برای پاسخ به کاربرانی که بدون داشتن مجوز لازم قصد دستکاری منابع را دارند

---

۴. جایگاه‌های تصاویر و نمودارها (Visual & Diagram Placeholders)

راهنمای ایجنت نویسنده: تمام تصاویر باید در پوشهٔ images/ قرار گرفته و در قالب جدول تک‌خانه‌ای وسط‌چین با کپشن تفصیلی درج شوند:

1. تصویر کاور درس: images/cover.png
   • موضوع: کاور مدرن با تم تیره و یک سپر دیجیتال نئونی که دور استوانه دیتابیس PostgreSQL تنیده شده و امواج غیرمجاز را دفع می‌کند.
2. استعاره نگهبان امنیتی RLS جلوی در دیتابیس: images/rls-bouncer-analogy.png
   • موضوع: تصویر استعاری: نگهبان امنیتی جلوی جدول (درخواست‌های بدون لاگین را به سمت در خروج هدایت می‌کند و به ادمین احراز هویت‌شده اجازه ورود می‌دهد).
3. مقایسه دیتابیس با و بدون RLS: images/unprotected-vs-rls-protected.png
   • موضوع: اینفوگرافیک مقایسه‌ای: سمت چپ دیتابیس بدون RLS (خطر پاک شدن کل اطلاعات توسط هر فرد) در برابر سمت راست دیتابیس قفل‌شده با RLS.
4. نشانگر سبز RLS در پنل Table Editor سوپابیس: images/supabase-rls-green-badge.png
   • موضوع: اسکرین‌شات تمیز از هدر جدول در Supabase با نشان دادن برچسب سبز RLS Enabled و لیست سیاست‌های فعال.
5. اسکریپت SQL سیاست‌های امنیتی پورتفولیو: images/sql-policies-code-block.png
   • موضوع: تصویر کادر کدهای SQL سیاست‌های خواندن عمومی و نگارش اختصاصی ادمین با هایلایت سینتکس تمیز.

---

۵. بخش‌بندی و ساختار محتوایی پیشنهادی درس‌نامه (README.md)

1. تیتر اصلی: # امنیت پایگاه داده با Row Level Security: ساخت دژ تسخیرناپذیر
2. مقدمه: چرا بدون RLS، انتشار یک اپلیکیشن متصل به دیتابیس معادل خودکشی سایبری است؟
3. جدول کاور درس
4. کابوس بزرگ: افشای کلید عمومی بدون سپر امنیتی: ریشه نیاز مبرم به RLS.
5. سازوکار Row Level Security (RLS) در PostgreSQL: امنیت در عمق دیتابیس، نه در جاوااسکریپت کلاینت.
6. سیاست‌های امنیتی پروژه پورتفولیوی پویا:
   • قانون خواندن عمومی کارهای پورتفولیو برای همه (SELECT Policy).
   • قانون انحصار ویرایش و حذف فقط برای ادمین تاییدشده (Authenticated Policy).
   • سیاست‌های جدول تک‌سطری سئو.
7. باکس نکته پیشرفته Quera (<details class="violet">): چرا چک‌های امنیتی فرانت‌اند هرگز کافی نیستند؟
8. اجرای اسکریپت فعال‌سازی و قفل‌گذاری RLS در SQL Editor: کپی و اجرای کوئری در چند ثانیه.
9. آزمون نفوذپذیری و تست زنده امنیت:
   • راستی‌آزمایی در تب ناشناس مرورگر.
   • اثبات مسدود شدن درخواست‌های غیرمجاز با خطای ۴۰۳.
10. باکس هشدار قرمز Quera (<details class="red">): هرگز پروژه‌ای را با RLS خاموش به پروداکشن نبرید!
11. جشن پایان فصل هفتم: اعلام آماده‌سازی ۱۰۰٪ فرانت‌اند، دیتابیس، احراز هویت و امنیت برای ورود به پروژه عملی اول (فصل ۸).

---

۶. معیارهای پذیرش (Acceptance Criteria for Reviewer)

• مفهوم RLS و خطرات غیرفعال بودن آن به زبانی رسا و هشداردهنده تبیین شده باشد.
• سیاست‌های امنیتی برای دو جدول projects و site_settings با کدهای کامل SQL ارائه گردند.
• تمایز دسترسی عمومی خواندن با دسترسی اختصاصی نگارش ادمین شفاف شده باشد.
• آزمون عملی تست سیاست‌ها با تب ناشناس مرورگر در متن گنجانده شود.