سوبابيز

# Supabase

## المبادئ الأساسية

**1. يتغير Supabase بشكل متكرر — تحقق من سجل التغييرات والوثائق الحالية قبل التنفيذ.** لا تعتمد على بيانات التدريب لميزات Supabase. تتغير توقيعات الدوال، وإعدادات config.toml، واتفاقيات API بين الإصدارات.

أولا، قم بجلب `https://supabase.com/changelog.md` (فهرس ملخص خفيف الوزن — وليس سحبا ثقيلا)، وابحث عن علامات `breaking-change` ذات الصلة بمهمتك، واتبع الصفحة المرتبطة لأي منها ينطبق. ثم ابحث عن الموضوع ذي الصلة باستخدام طرق الوصول إلى الوثائق أدناه.

**2. تحقق من عملك.** بعد تنفيذ أي إصلاح، قم بتشغيل استعلام اختباري لتأكيد أن التغيير يعمل. الإصلاح بدون تحقق يعتبر غير مكتمل.

**3. تعاف من الأخطاء، لا تكرر.** إذا فشل نهج بعد محاولتين أو ثلاث، توقف وأعد النظر. جرب طريقة مختلفة، تحقق من الوثائق، افحص الخطأ بعناية أكبر، وراجع السجلات ذات الصلة عند توفرها. لا تحل مشكلات Supabase دائما بإعادة محاولة نفس الأمر، والإجابة ليست دائما في السجلات، ولكن غالبا ما تستحق السجلات المراجعة قبل المتابعة.

**4. كشف الجداول ل Data API:** اعتمادا على [إعدادات Data API](https://supabase.com/dashboard/project/<ref>/integrations/data_api/settings) الخاصة بالمستخدم، قد لا يتم كشف الجداول التي تم إنشاؤها حديثا تلقائيا عبر Data (REST) API. إذا كان هذا هو الحال، ستحتاج أدوار `anon` و `authenticated` إلى منح الوصول بشكل صريح.

> لاحظ أن هذا منفصل عن RLS، الذي يتحكم في _الصفوف_ المرئية بمجرد أن يصبح الجدول قابلا للوصول، وليس ما إذا كان الجدول قابلا للوصول على الإطلاق.

عندما يبلغ مستخدم أن جدولا تم إنشاؤه بواسطة SQL غير قابل للوصول بشكل غير متوقع، تحقق من إعدادات Data API الخاصة به وما إذا تم منح الأدوار حق الوصول عبر `GRANT` SQL صريح. عند منح الوصول العام (`anon`/`authenticated`)، قم دائما بتمكين RLS أيضا. راجع [Exposing a Table to the Data API](https://supabase.com/docs/guides/api/securing-your_api.md) لسير عمل الإعداد الكامل.

**5. RLS في المخططات المكشوفة.** قم بتمكين RLS على كل جدول في أي مخطط مكشوف، والذي يتضمن `public` افتراضيا. هذا أمر بالغ الأهمية في Supabase لأن الجداول في المخططات المكشوفة يمكن الوصول إليها من خلال Data API عندما يكون لأدوار `anon`/`authenticated` حق الوصول (انظر [Exposing a Table to the Data API](https://supabase.com/docs/guides/api/securing-your-api.md)). بالنسبة للمخططات الخاصة، يفضل RLS كدفاع متعمق. بعد تمكين RLS، قم بإنشاء سياسات تتطابق مع نموذج الوصول الفعلي بدلا من تعيين كل جدول افتراضيا على نفس نمط `auth.uid()`.

**6. قائمة التحقق الأمني.** عند العمل على أي مهمة في Supabase تتعلق بالمصادقة (auth)، أو RLS، أو العروض (views)، أو التخزين، أو بيانات المستخدم، قم بمراجعة قائمة التحقق هذه. هذه هي فخاخ أمنية خاصة ب Supabase تنشئ نقاط ضعف بصمت:

- **أمن المصادقة والجلسات** - **لا تستخدم أبدا مطالبات `user_metadata` في قرارات التفويض المستندة إلى JWT.** في Supabase، `raw_user_meta_data` قابلة للتعديل من قبل المستخدم ويمكن أن تظهر في `auth.jwt()`، لذا فهي غير آمنة لسياسات RLS أو أي منطق تفويض آخر. قم بتخزين بيانات التفويض في `raw_app_meta_data` / `app_metadata` بدلا من ذلك. - **حذف المستخدم لا يبطل رموز الوصول الموجودة.** قم بتسجيل الخروج أو إلغاء الجلسات أولا، حافظ على صلاحية JWT قصيرة للتطبيقات الحساسة، ولضمانات صارمة قم بالتحقق من `session_id` مقابل `auth.sessions` في العمليات الحساسة. - **إذا كنت تستخدم `app_metadata` أو `auth.jwt()` للتفويض، تذكر أن مطالبات JWT ليست دائما حديثة حتى يتم تحديث رمز المستخدم.**

- **مفتاح API وكشف العميل** - **لا تكشف أبدا `service_role` أو المفتاح السري في العملاء العامين.** فضل المفاتيح القابلة للنشر لرمز الواجهة الأمامية. مفاتيح `anon` القديمة هي للتوافق فقط. في Next.js، يتم إرسال أي متغير بيئة `NEXT_PUBLIC_` إلى المتصفح. - **استخدم رموز الوصول الشخصية المحددة النطاق ل Management API، و CLI، وخادم MCP.** يحمل رمز الوصول الشخصي الكلاسيكي وصول حساب المستخدم الكامل، على كل مؤسسة ومشروع. بالنسبة للبرامج النصية، و CI، والوكلاء، اطلب من المستخدم إنشاء رمز محدد النطاق يقتصر على المؤسسات والمشاريع والأذونات التي تحتاجها المهمة. يسرد [دليل رموز الوصول الشخصية](https://supabase.com/docs/guides/platform/personal-access-tokens.md) الأذونات التي تتطلبها كل نقطة نهاية Management API وأداة MCP. ابحث عن الأذونات هناك بدلا من التخمين.

- **RLS، والعروض، ورمز قاعدة البيانات المتميز** - **تتجاوز العروض RLS افتراضيا.** في Postgres 15 وما فوق، استخدم `CREATE VIEW ... WITH (security_invoker = true)`. في الإصدارات الأقدم من Postgres، قم بحماية عروضك عن طريق إلغاء الوصول من أدوار `anon` و `authenticated`، أو عن طريق وضعها في مخطط غير مكشوف. - **يتطلب UPDATE سياسة SELECT.** في Postgres RLS، يحتاج UPDATE أولا إلى SELECT الصف. بدون سياسة SELECT، تعيد التحديثات بصمت 0 صفوف — لا يوجد خطأ، فقط لا يوجد تغيير. - **`auth.role()` مهمل — استخدم عبارة `TO` بدلا من ذلك.** لقد أهملت Supabase `auth.role()` لصالح تحديد الدور المستهدف مباشرة على السياسة باستخدام `TO authenticated` أو `TO anon`. بالإضافة إلى الإهمال