دليل كامل للتحكم في الوصول المستند للأدوار (RBAC): التحكم في تصميم الأذونات وإدارة الأدوار والتفويض الآمن مع تنفيذ عملي لنظام إدارة المحتوى (CMS).
هل تعاني من تنفيذ نظام تفويض آمن وقابل للتوسع لتطبيقك؟ التحكم في الوصول المستند للأدوار (RBAC) هو المعيار الصناعي لإدارة أذونات المستخدمين، لكن تنفيذه بشكل صحيح يمكن أن يكون تحديًا. سيعرض لك هذا الدليل كيفية بناء نظام RBAC قوي باستخدام مثال حقيقي لنظام إدارة المحتوى (CMS).
باتباع هذا الدليل، ستتعلم:
الشفرة المصدرية الكاملة لهذا الدليل متاحة على GitHub.
التحكم في الوصول المستند للأدوار ليس مجرد تعيين أذونات للمستخدمين. إنها عن خلق نهج منظم للتفويض يوازن بين الأمان وسهولة الصيانة.
يمكنك معرفة المزيد عن ما هو RBAC في Auth Wiki.
ها هي المبادئ الرئيسية التي سنتبعها في تنفيذنا:
الأذونات الدقيقة تمنحك تحكمًا دقيقًا فيما يمكن للمستخدمين فعله في نظامك. بدلاً من مستويات الوصول الواسعة مثل "admin" أو "user"، نقوم بتحديد الإجراءات المحددة التي يمكن للمستخدمين القيام بها على الموارد. على سبيل المثال:
read:articles - عرض أي مقال في النظامcreate:articles - إنشاء مقالات جديدةupdate:articles - تعديل المقالات القائمةpublish:articles - تغيير حالة نشر المقالاتملكية الموارد هي مفهوم أساسي في تصميم التفويض لنظام إدارة المحتوى (CMS) لدينا. بينما يحدد RBAC ما يمكن للأدوار المختلفة القيام به، تضيف الملكية بُعدًا شخصيًا إلى التحكم في الوصول:
update:articles، يمكن للكاتب تعديل مقالاته الخاصةهذا النهج ذو الطبقتين (الأدوار + الملكية) يخلق نظامًا أكثر بديهية وأمانًا. الناشرين والمدراء يمكنهم أيضًا إدارة كل المحتوى من خلال أذونات الأدوار الخاصة بهم، بينما يحتفظ الكتّاب بالتحكم في أعمالهم الخاصة.
لنبدأ بتصميم الوظيفة الأساسية لنظام إدارة المحتوى (CMS) الخاص بنا من خلال نقاط النهاية لواجهة برمجة التطبيقات:
بالنسبة لكل نقطة نهاية، نحتاج إلى مراعاة جانبين من التحكم في الوصول:
إليك كيفية معالجة الوصول لكل نقطة نهاية:
| نقطة النهاية | منطق التحكم في الوصول |
|---|---|
| GET /api/articles | - أي شخص لديه إذن list:articles، أو الكتّاب يمكنهم رؤية مقالاتهم الخاصة |
| GET /api/articles/:id | - أي شخص لديه إذن read:articles، أو كاتب المقال |
| POST /api/articles | - أي شخص لديه إذن create:articles |
| PATCH /api/articles/:id | - أي شخص لديه إذن update:articles، أو كاتب المقال |
| DELETE /api/articles/:id | - أي شخص لديه إذن delete:articles، أو كاتب المقال |
| PATCH /api/articles/:id/published | - فقط المستخدمون لديهم إذن publish:articles |
بناءً على متطلبات الوصول لواجهة برمجة التطبيقات، يمكننا تعريف هذه الأذونات:
| الإذن | الوصف |
|---|---|
| list:articles | عرض قائمة بجميع المقالات في النظام |
| read:articles | قراءة محتوى أي مقال |
| create:articles | إنشاء مقالات جديدة |
| update:articles | تعديل أي مقال |
| delete:articles | حذف أي مقال |
| publish:articles | تغيير حالة النشر |
لاحظ أن هذه الأذونات مطلوبة فقط عند الوصول إلى موارد لا تملكها. يمكن لأصحاب المقالات تلقائيًا:
read:articles)update:articles)delete:articles)الآن بعد أن حددنا واجهة برمجة التطبيقات والأذونات، يمكننا إنشاء أدوار تجمع بين هذه الأذونات بشكل منطقي:
| الإذن/الدور | 👑 مدير | 📝 ناشر | ✍️ كاتب |
|---|---|---|---|
| الوصف | وصول كامل للنظام لإدارة المحتوى بالكامل | يمكنه عرض جميع المقالات والتحكم في حالة النشر | يمكنه إنشاء مقالات جديدة في النظام |
| list:articles | ✅ | ✅ | ❌ |
| read:articles | ✅ | ✅ | ❌ |
| create:articles | ✅ | ❌ | ✅ |
| update:articles | ✅ | ❌ | ❌ |
| delete:articles | ✅ | ❌ | ❌ |
| publish:articles | ✅ | ✅ | ❌ |
ملاحظة: الكتّاب لديهم تلقائيًا أذونات للقراءة والتحديث والحذف لمقالاتهم الخاصة، بغض النظر عن أذونات الأدوار.
كل دور مصمم بمسؤوليات محددة في الاعتبار:
هذا التصميم الدور يخلق فصلًا واضحًا للمسؤوليات:
قبل البدء، تحتاج إلى إنشاء حساب في Logto Cloud، أو يمكنك أيضًا استخدام نسخة Logto ذات الاستضافة الذاتية باستخدام الإصدار مفتوح المصدر من Logto.
لكن في هذا الدليل، سنستخدم Logto Cloud للبساطة.
list:articlesread:articlescreate:articlesupdate:articlespublish:articlesdelete:articles
انتقل إلى الأدوار في وحدة التحكم Logto لإنشاء الأدوار التالية لنظام إدارة المحتوى
read:articles, list:articles, publish:articlescreate:articles
انتقل إلى قسم "إدارة المستخدمين" في وحدة التحكم Logto لإنشاء مستخدمين.
في علامة تبويب "الأدوار" في تفاصيل المستخدم، يمكنك تعيين أدوار للمستخدم.
في مثالنا، نقوم بإنشاء 3 مستخدمين بالأدوار التالية:
الآن، قمنا بإعداد RBAC في Logto، يمكننا البدء في دمجه في الواجهة الأمامية الخاصة بنا.
ثم اتبع دليل البدء السريع في Logto لدمج Logto في التطبيق الخاص بك.
في مثالنا، نستخدم React للعرض.
بعد إعداد Logto في التطبيق الخاص بك، نحتاج إلى إضافة تكوينات RBAC ليعمل Logto.
تذكر تسجيل الخروج وتسجيل الدخول مرة أخرى لجعل هذا التغيير ساريًا إذا كنت قد سجلت الدخول بالفعل.
عندما يسجل المستخدم الدخول باستخدام Logto ويطلب رمز الوصول لموارد واجهة برمجة التطبيقات المحددة أعلاه، سيضيف Logto النطاقات (الأذونات) المتعلقة بدور المستخدم إلى رمز الوصول.
يمكنك استخدام getAccessTokenClaims من الـ useLogto للحصول على النطاقات من رمز الوصول.
ويمكنك استخدام userScopes للتحقق مما إذا كان لدى المستخدم الإذن للوصول إلى المورد.
حان الوقت الآن لدمج RBAC في Logto في الخلفية الخاصة بك.
أولاً، نحتاج إلى إضافة وسيط في الخلفية للتحقق من أذونات المستخدم، التحقق مما إذا كان المستخدم متصلاً، وتحديد ما إذا كان لديه الأذونات اللازمة للوصول إلى بعض واجهات برمجة التطبيقات.
كما ترى، في هذا الوسيط، نتحقق مما إذا كان طلب الواجهة الأمامية يحتوي على رمز وصول صالح ونتحقق مما إذا كان الجمهور المتواجد في رمز الوصول يتطابق مع مورد واجهة برمجة التطبيقات الذي أنشأناه في وحدة التحكم Logto.
السبب في التحقق من مورد واجهة برمجة التطبيقات هو أن مورد واجهة برمجة التطبيقات لدينا يمثل فعليًا موارد خادمنا الخلفي CMS، وجميع أذونات CMS لدينا مرتبطة بمورد واجهة برمجة التطبيقات هذا.
نظرًا لأن مورد واجهة برمجة التطبيقات هذا يمثل موارد CMS في Logto، في رمز الواجهة الأمامية الخاص بنا، ندرج رمز الوصول المقابل عند إجراء طلبات واجهة برمجة التطبيقات إلى الخادم الخلفي:
الآن يمكننا استخدام وسيلة requireAuth لحماية نقاط نهاية واجهة برمجة التطبيقات الخاصة بنا.
بالنسبة لواجهات برمجة التطبيق التي يجب أن تكون قابلة للوصول فقط للمستخدمين الحاصلين على أذونات محددة، يمكننا إضافة قيود مباشرة في الوسيط. على سبيل المثال، يجب أن تكون واجهة برمجة التطبيق لإنشاء المقالات قابلة للوصول فقط للمستخدمين الحاصلين على إذن create:articles:
بالنسبة لواجهات برمجة التطبيق التي تحتاج إلى التحقق من كل من الأذونات وملكية الموارد، يمكننا استخدام وظيفة hasScopes. على سبيل المثال، في واجهة برمجة التطبيق لقائمة المقالات، يمكن للمستخدمين الذين لديهم إذن list:articles الوصول إلى جميع المقالات، بينما يمكن للكتّاب الوصول إلى مقالاتهم الخاصة التي تم إنشاؤها:
عند هذه النقطة، نحن قد أتممنا تنفيذ RBAC. يمكنك الاطلاع على الشفرة المصدرية الكاملة لرؤية التنفيذ الكامل.
الآن، دعونا نختبر تنفيذ RBAC لنظام CMS باستخدام المستخدمين الثلاثة الذين أنشأناهم للتو.
أولاً، دعونا نقوم بتسجيل الدخول كلاً من أليكس وتشارلي على التوالي وإنشاء بعض المقالات.
نظرًا لأن أليكس يمتلك دور المدير، فيمكنه إنشاء، حذف، تحديث، نشر، وعرض جميع المقالات.
تشارلي، صاحب دور الكاتب، يمكنه فقط إنشاء مقالاته الخاصة ولا يمكنه سوى عرض، تحديث، وحذف مقالاته الخاصة.
بوب، الذي يمتلك دور الناشر، يمكنه عرض ونشر جميع المقالات لكن لا يمكنه إنشاء، تحديث، أو حذفها.
تهانينا! لقد تعلمت كيفية تنفيذ نظام RBAC قوي في تطبيقك.
بالنسبة للسيناريوهات الأكثر تعقيدًا، مثل بناء تطبيقات متعددة المستأجرين، يوفر Logto دعم شامل للمنظمات. تحقق من دليلنا بناء تطبيق SaaS متعدد المستأجرين: دليل كامل من التصميم إلى التنفيذ لتتعلم المزيد عن تنفيذ التحكم في الوصول على مستوى المنظمة.
برمجة سعيدة! 🚀