# مشخصات درس‌نامه: امنیت پایگاه داده با 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`):**
     * **قانون ۱ (خواندن برای عموم آزاد):** همه افراد در جهان باید بتوانند نمونه‌کارها را ببینند:
       ```sql
       CREATE POLICY "Public projects are viewable by everyone" 
       ON projects FOR SELECT 
       USING (true);
       ```
     * **قانون ۲ (فقط ادمین لاگین‌شده حق ویرایش دارد):** فقط کاربری که با موفقیت در Supabase Auth لاگین کرده اجازه ثبت، ویرایش و حذف دارد:
       ```sql
       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:**
   * دستورات صریح فعال‌سازی:
     ```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 ارائه گردند.
- [ ] تمایز دسترسی عمومی خواندن با دسترسی اختصاصی نگارش ادمین شفاف شده باشد.
- [ ] آزمون عملی تست سیاست‌ها با تب ناشناس مرورگر در متن گنجانده شود.