مختبر يختبر عزل سجلات كل جهة: مشاريع تخرج قواعد البيانات

في تطبيق متعدد الجهات، قد يحتوي الجدول نفسه سجلات تخص مختبراً وجمعية ومركزاً طلابياً. خطأ صغير في شرط WHERE يعرّض صفاً من tenant إلى tenant آخر. يضع مشروع تخرج قواعد البيانات سياسات PostgreSQL في سياقها الصحيح، ويختبر SELECT وINSERT وUPDATE وDELETE بأدوار مختلفة. توثيق Row Security يوضح أن تفعيل RLS يجعل الوصول العادي خاضعاً للسياسات، وأن تجاوزها مرتبط بأدوار وامتيازات خاصة. الأداة لا تصادق المستخدم ولا تثبت أن التطبيق يمرر tenant id موثوقاً؛ هي تختبر طبقة قاعدة البيانات على مخطط مصطنع.

وتناسب الفكرة مشاريع تخرج قواعد البيانات عندما يحدد الفريق نطاقاً صغيراً، ويعرض حالات النجاح والفشل في تقرير يمكن للمشرف إعادة تشغيله.

ابدأ بجهتين وبيانات يسهل تمييزها

أنشئ جدول documents يحوي id وtenant_id وlabel، ثم أضف صفاً يحمل علامة A وصفاً يحمل علامة B. أنشئ دورين عاديين لدخول المختبر، لا superuser ولا مالك الجدول. اجعل التوقع أن يرى كل دور صفوف جهته فقط. سجل حالة الاتصال الحالية واسم الدور وtenant setting بعد كل خطوة، لكن لا تستعمل قاعدة حقيقية. ضع الصفوف في seed ثابت حتى يمكن إعادة كل test من الحالة نفسها. الأسماء الاصطناعية تمنع اختلاط المثال بتطبيق قائم وتساعد الطالب على قراءة سبب السماح أو المنع.

اكتب السياسة وارسم اتجاهها

فعّل row-level security على الجدول، ثم اكتب سياسة USING تحدد الصفوف التي يسمح للدور بقراءتها أو تعديلها، وسياسة WITH CHECK تتحقق من الصف الناتج بعد INSERT أو UPDATE. وثائق CREATE POLICY تفرق بين شروط الصف الموجود والصف الجديد. لا تكتب المثال كأن شرطاً واحداً يغطي دائماً كل العمليات؛ اختبر command وrole target على حدة. إذا استخدمت قيمة session variable للـtenant، أظهر من يضبطها ومتى، ولا تسمح للمستخدم بتغييرها إلى tenant آخر في المسار التطبيقي.

نفّذ الحالات تحت الدور الحقيقي

بدّل الدور عبر SET ROLE داخل جلسة الاختبار، ثم نفذ query في transaction مع إعادة ضبط السياق قبل الحالة التالية. اختبر SELECT بلا tenant، وإدخال tenant_id غير مسموح، وتحديث صف من الجهة الأخرى، ومحاولة نقل صف من A إلى B. افحص أثر owner bypass وBYPASSRLS في نسخة اختبار منفصلة؛ لا تشغل الفاحص كمالك الجدول ثم تستنتج أن الدور العادي محمي. سجل كل SQL ونتيجته واسم الدور، مع إخفاء أي قيمة اتصال أو كلمة مرور.

اكتب مصفوفة متوقعة قبل التنفيذ

أنشئ جدولاً صفوفه العمليات وأعمدته: role A، role B، الدور المشرف، وبدون tenant context. لكل خانة توقع واضح: يرى الصف، يرى صفاً فارغاً، أو يرفض العملية. حالة UPDATE قد تنجح بلا تغيير إذا كان الصف مخفياً، لذلك افحص عدد الصفوف المتأثرة ولا تكتف بكلمة success. اختبر default deny حين لا توجد policy، والامتيازات العادية على عمليات عدة. لا تخلط أمن الصفوف بقيود UNIQUE أو FK؛ قد تظل بعض القيود تكشف وجود قيمة أو تتفاعل بطريقة مختلفة.

أعد التشغيل بعد تعديل كل سياسة

يولد المختبر تقريراً عن كل حالة: SQL fixture، الدور، التوقع، النتيجة الفعلية، وعدد الصفوف المتأثرة. أضف migration يغير policy ثم أعد المجموعة على نسختين متتاليتين، وتأكد أن seed يعود إلى حالة نظيفة. اختبر حالات فشل الاتصال والرجوع من transaction كي لا تتسرب قيمة tenant setting إلى الطلب التالي في pooled connection. ضع اختباراً يجمع طلبين من جهتين في الجلسة ذاتها إذا كان التصميم يسمح بإعادة الاتصال، وتحقق من reset. هذه اختبارات ضرورية في النموذج، لكنها لا تغطي كل المسارات أو الأدوار الفعلية للإنتاج.

سمّ حدود الضمان بصراحة

RLS طبقة دفاع مهمة، لكنها لا تصلح التطبيق تلقائياً إذا كان اتصال التطبيق يملك امتياز تجاوز السياسة، أو إذا كان الدور يستطيع تبديل tenant context بلا تحقق. كذلك قد يكشف ترتيب الأخطاء أو قيود التفرد معلومات غير مباشرة. لا تستخدم قاعدة طلاب حقيقية أو تمنح المتعلم وصولاً إلى قاعدة حية. خل التقرير يحدد الأدوار التي اختبرها ونسخة PostgreSQL والسياسات والـgrants. على الفريق مراجعة مصدر tenant id والتخزين في connection pool قبل وصف النظام بأنه معزول.

ما الذي يتسلمه المشرف؟

يشمل التسليم مخطط SQL وseed ومصفوفة الحالات والنتائج الآلية ودليل تشغيل قاعدة محلية. يرتبط ذلك بـمشاريع التخرج وخدمة قواعد البيانات وواجهات البرمجة. المساهمة العلمية للمشروع هي مجموعة تحقق محددة ضد تسرب الصفوف في سيناريوهات معلنة؛ لا تدعي فحص كل ثغرات التطبيق. يعرض التقرير حتى الاختبارات الفاشلة بدلاً من حذفها، ويتيح لزميل تشغيل fixture مستقل ليتأكد من أن الحماية قائمة تحت الدور المقصود.