feat: add chapter 07-database-and-backend specs

2026-09-05 22:15:28 +08:00
parent 405cab3828
commit d6c371f485
8 changed files with 858 additions and 0 deletions
--- a/chapters/07-database-and-backend/07-lesson-database-security-rls/spec.md
+++ b/chapters/07-database-and-backend/07-lesson-database-security-rls/spec.md
@@ -0,0 +1,119 @@
+# مشخصات درس‌نامه: امنیت پایگاه داده با 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 ارائه گردند.
+- [ ] تمایز دسترسی عمومی خواندن با دسترسی اختصاصی نگارش ادمین شفاف شده باشد.
+- [ ] آزمون عملی تست سیاست‌ها با تب ناشناس مرورگر در متن گنجانده شود.