تصميم تسجيل الدخول والصلاحيات في مشروع جامعي

قد يسجل الطالب دخوله بنجاح ثم يحاول تعديل حجز طالب آخر. هنا لا يكفي التحقق من هويته؛ يجب أن يقرر الخادم هل يملك حق تنفيذ العملية على هذا الحجز. هذا هو الفرق بين المصادقة Authentication والتفويض Authorization. سنكتب سياسة وصول لنظام حجز واختبارات لفصل المستخدمين، مع الاعتماد على مكونات الإطار الموثوقة لإدارة كلمات المرور والجلسات.

حدد الموارد والأفعال

في نظام حجز مختبر تعليمي، الموارد هي الأجهزة والحجوزات وفترات الصيانة. الأفعال تشمل العرض والإنشاء والإلغاء وإدارة الجهاز. بعض القواعد تعتمد دور المستخدم، وبعضها يعتمد علاقته بالمورد، مثل كونه مالك الحجز. لذلك لا يكفي حقل role وحده لشرح السياسة كلها.

اكتب كيف يُمنح الدور ومن يستطيع تغييره وما يحدث للحساب المعطل. لا تسمح لطلب تسجيل مستخدم جديد باختيار دور مدير لأن الحقل موجود في JSON. ولا تأخذ المالك من جسم الطلب عند إنشاء حجز مستخدم عادي؛ استخرجه من الهوية المتحقق منها في الخادم.

من يقرأ الحجز ومن يستطيع تعديله؟

المصفوفة مقترحة وليست وصفاً لصلاحيات جامعة فعلية. إذا كان المشروع يضم عدة مختبرات، لا تجعل دور المسؤول مفتاحاً لكل البيانات تلقائياً. أضف علاقة اختصاص واضحة، واختبر محاولة المسؤول الوصول إلى مختبر آخر. وعندما لا توجد قاعدة تسمح بالفعل، يكون الرفض هو القرار الافتراضي وفق إرشادات OWASP للتفويض.

صمم مسار الدخول والجلسة

1. يتلقى الخادم بيانات الدخول عبر HTTPS في البيئة المنشورة.
2. يتحقق منها بمكوّن المصادقة في الإطار ويطبق ضوابط محاولات الدخول المناسبة.
3. ينشئ جلسة أو رمزاً وفق معمارية التطبيق، مع انتهاء وإبطال موثقين.
4. يتحقق كل طلب محمي من الهوية والحالة والصلاحية وملكية المورد.
5. ينهي تسجيل الخروج الجلسة بالطريقة الصحيحة للمكوّن المستخدم.

في تطبيق متصفح يعتمد Cookies، راجع HttpOnly وSecure وSameSite وحماية CSRF ضمن إعدادات الإطار. هذه الإعدادات مترابطة مع أصل الواجهة والخادم وطريقة النشر؛ لا تنسخ قيماً عشوائية لحل مشكلة محلية ثم ترفعها إلى الإنتاج. وفي تطبيق يستخدم Tokens، لا تعتبر وجود JWT بحد ذاته دليلاً على تحقق توقيعه أو صلاحيته.

توضح وثائق OWASP للمصادقة أهمية رسائل دخول لا تكشف وجود حساب بعينه. اكتب رسالة عامة مناسبة عند فشل التحقق، ولا ترسل للعميل تفاصيل القاعدة أو قيمة التشفير. واجعل استعادة الحساب وظيفة حقيقية عبر آلية موثوقة، لا صفحة تعرض نجاحاً دون إرسال أو تحقق.

اختبر فصل المستخدمين بطلب مباشر

أنشئ حسابي تجربة A وB، واجعل لكل منهما حجزاً مختلفاً. سجّل الدخول بحساب A ثم أرسل طلب عرض أو إلغاء بمعرف حجز B. النتيجة المطلوبة وفق العقد هي رفض الوصول وعدم تعديل البيانات؛ قد يختار النظام 403 أو إخفاء المورد بـ404، لكن يجب أن يكون ذلك متسقاً ومقصوداً.

ما الذي تسجله عن محاولات الوصول؟

قد تحتاج سجل عمليات يذكر الفعل والمورد والنتيجة ومعرف تتبع وهوية داخلية مناسبة للوصول المصرح، لكن لا تسجل كلمات المرور أو رموز الجلسات. ولا ترسل نص رسالة العميل أو بياناته الشخصية إلى Analytics لمراقبة زر الدخول. حدد من يستطيع قراءة السجل ومدة الاحتفاظ بما يتوافق مع حاجة المشروع.

تحقق من الصلاحية في كل طلب، بما في ذلك طلبات واجهة الإدارة. وراجع قائمة النشر إذا استخدمت Django أو المرجع الموافق لتقنيتك. لم تُنفذ الحالات المقترحة هنا على تطبيق قائم، ولا تمثل تدقيقاً أمنياً له. عند طلب تطوير مشروع برمجي، أرفق جدول الأدوار ونطاق السجلات والعمليات التي يحتاج كل مستخدم إلى تنفيذها.