كيفية التعامل بشكل أفضل مع الأذونات (وليس الأدوار) في عضوية asp.net، وتحديدًا في ASP.NET MVC

Question

هناك الكثير من الأسئلة (والمعلومات) حول إعداد عضوية asp.net وموفري الأدوار وما شابه.ما إذا كان يجب عليك استخدام النظام الأساسي المدمج الذي توفره Microsoft أم لا، أو توسيع الدور للفئات الأساسية ودورك الخاص.

لقد قررت توسيع نطاق الموفرين الافتراضيين وتنفيذ موفري العضوية والأدوار الخاصين بي.سؤالي الآن يتعلق تحديدًا بمصادقة الدور.

تقليديًا، يمكنك إنشاء أدوار ربما مثل "المدير أو المسؤول أو الموظف أو المستخدم المتميز" أو أي شيء لديك.ولكن ماذا ستفعل/ينبغي عليك فعله فيما يتعلق بالأذونات التي أعتبرها بمثابة قدر أكبر من التحكم؟اسمحوا لي أن أشرح ....

لدي ضمن موقع asp.net mvc الخاص بي مجالات مختلفة مثل الإدارة والتنظيم والمراسلة وإعداد التقارير وما إلى ذلك.أود أن أصنف الأدوار لكل من هذه الأدوار مثل "المسؤول" و"المدير" و"المراسل" وما إلى ذلك.بدون الدور المناسب، لا يمكنك الوصول إلى تلك المنطقة من الموقع.لذلك أود قفل وحدات التحكم بالكامل بهذا على مستوى الفصل.

لكن الآن خذ منطقة واحدة كمثال؛المراسلة، وأقول إنني أرغب في الحصول على أذونات أفضل للحبوب لـ CRUD؛إنشاء رسالة وعرض/قراءة الرسائل وتحرير الرسائل وحذف الرسائل وما إلى ذلك.

وأخيرا سؤالي.كيف سيكون من الأفضل تنفيذ هذه الحبوب الدقيقة من التحكم؟أحد الأساليب التي أراها (لست متأكدًا مما إذا كانت جيدة) هو إنشاء أدوار عضوية asp.net لكل شيء.لذلك ربما أكون قد....

Messenger (دور واسع المستوى)، CreateMessage، ReadMessage، EditMessage، DeleteMessage.

من ناحية، أود أن يتمكن بعض المستخدمين من قراءة/عرض الرسائل.ولكن ليس بالضرورة إنشائها أو حذفها.يمكن أن يتم تطبيق الأدوار المحددة لإجراءات وحدة التحكم الفردية.

هل ترى أي مشاكل مع هذا النهج؟هل تمتلك فكرة افضل؟

الحل حتى الآن

لقد قررت إنشاء المخطط الخاص بي وتنفيذ موفري العضوية والأدوار المخصصة.يتضمن مخططي؛

• مستخدم
• ملف تعريفي للمستخدم
• إذن
• تعيين الإذن
• دور
• تعيين الدور

سأغيب لليوم أو اليومين التاليين ولكن سأقوم بالتحديث بمزيد من المعلومات عندما تسنح لي الفرصة.

Answer 1

أعتقد أنه يجب عليك نسيان الأدوار الموجودة في آلية التفويض، وطلب الأذونات بدلاً من ذلك (في النهاية، الدور عبارة عن مجموعة من الأذونات)، لذلك إذا نظرت إلى الأمر بهذه الطريقة، Authorize يجب أن تطلب السمة كيانًا وإجراءً، وليس دورًا معينًا.شيء مثل:

[Authorize(Entities.Message, Actions.Create)]
public ActionResult CreateMessage()

[Authorize(Entities.Message, Actions.Edit)]
public ActionResult EditMessage()

[Authorize(Entities.Message, Actions.View)]
public ActionResult ViewMessage()

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

يحرر: للتعامل مع قواعد محددة مثل تلك التي أشار إليها ديفيد روبنز، لا يُسمح للمدير أ بحذف الرسائل التي أنشأها المدير ب، بافتراض أن كلاهما لديه الإذن المطلوب للوصول إلى إجراء وحدة التحكم هذا، فإن المفوض ليس مسؤولاً عن التحقق من هذا النوع من القواعد، وحتى إذا حاولت التحقق من ذلك على مستوى عامل تصفية الإجراء، فسيكون الأمر مؤلمًا، لذلك ما يمكنك فعله هو توسيع نطاق التحقق من التفويض إلى ActionResult (حقن معلمة إجراء تحتفظ بنتيجة التحقق)، والسماح لـ ActionResult باتخاذ القرار المنطقي هناك مع كل الحجج في مكانها.

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

Answer 2

فيما يتعلق بمثال CRUD الخاص بك، ألا تتحدث حقًا عن التفويض، وهل سيختلف التفويض بين أدوار العضوية "المدير" و"المراسل"؟أعتقد أنك بحاجة إلى إنشاء آلية منفصلة لتلك الأنشطة الدقيقة إذا كانت الأدوار لا تميز بين تفويض القراءة والكتابة بين الرسائل.

إذا كنت تريد إنشاء دور لكل إجراء - EditMessage وDeleteMessage - فماذا ستفعل في حالة عدم قدرة المدير "أ" على حذف رسائل المدير "ب"؟

Answer 3

وكذلك إضافة [Authorize(Roles="Administrator")] إلخ فوق وحدة التحكم الخاصة بك.بامكانك ايضا ضع تلك السمة على الإجراءات الفردية أيضاً