أفضل طريقة لتنفيذ التفويض الدقيق لتطبيق ويب؟

Question

أنا أعمل على تطبيق ويب Rails، ويستخدمه حاليًا حوالي 20 مستخدمًا.

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

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

ومن ناحية أخرى، يرى المستخدمون الروابط المؤدية إلى الإجراءات التي ليس لديهم امتيازات كافية لها.على سبيل المثال، يرى العاملون في قسم المبيعات رابطًا للسجلات المالية في القائمة الرئيسية، ولكن عندما ينقرون عليه، لا يحدث شيء.وذلك لأن AFAIK لا توجد طريقة فعالة للاستعلام عن امتيازات المستخدم باستخدام Acts_as_authenticated.

أريد تغيير هذا بطريقتين:

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

2. أريد أن أكون قادرًا على الاستعلام عن امتيازات المستخدم بكفاءة، حتى أتمكن من إزالة الروابط غير الضرورية (والمربكة) من الواجهة.

ما رأيك هي الطريقة الأكثر أناقة لتنفيذ ذلك؟

الإجابات الخاصة بـ Rails ليست ضرورية، أريد فقط أن أعرف كيف ينبغي تنفيذ ذلك في تطبيق يعتمد على البيانات.

وأخيرًا، إليك كيفية تنفيذه حاليًا:

def authorized?
  current_user.role.foo? or current_user.role.bar?
end

وهذه هي فكرتي الأولية، والتي أعتقد أنها ليست أفضل طريقة لحل هذه المشكلة:

+------------+------------+---------+
| department | controller | action  |
+------------+------------+---------+
| accounting | payments   | index   |
| accounting | payments   | new     |
| accounting | payments   | create  |
| accounting | payments   | edit    |
| accounting | payments   | update  |
| accounting | payments   | destroy |
| sales      | payments   | new     |
| sales      | payments   | create  |
| sales      | payments   | edit    |
| sales      | payments   | update  |
+------------+------------+---------+

أو

+------------+----------+-------+--------+------+--------+--------+
| department | model    | list  | create | read | update | delete |
+------------+----------+-------+--------+------+--------+--------+
| accounting | payments | TRUE  | TRUE   | TRUE | TRUE   | TRUE   |
| sales      | payments | FALSE | TRUE   | TRUE | TRUE   | FALSE  |
+------------+----------+-------+--------+------+--------+--------+

Answer 1

المفهوم الأساسي للترخيص، كما أفهمه، هو الدور.الدور يمكن أن يعبر عن أشياء مختلفة:

1. علاقة المستخدم بالنظام ككل (على سبيل المثال.أن يكون مسؤولاً عن النظام)
2. علاقة المستخدم بنوع ما من الكيانات (على سبيل المثال.ليكون مشرفا على التعليقات)
3. علاقة المستخدم ببعض الكيانات المحددة (على سبيل المثال.أن تكون مالكًا لبعض الموارد)
4. بعض العلاقات المعقدة الأخرى (على سبيل المثال.أن تكون صديقًا لمستخدم مالك لبعض الموارد)
5. يمتلك هذا المستخدم بعض السمات (السمات) أو يستجيب لبعض الرسائل بطريقة معينة (على سبيل المثال.أن تكون مراهقا)

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

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

الطريقة التي تناسبني في Rails هي تحديد الأدوار على مستوى النموذج وترك آلية التفويض (تعيين الأدوار المسموح بها لأجزاء من التعليمات البرمجية التي أريد ترخيصها والسؤال عما إذا كان المستخدم الحالي لديه الدور المسموح له بتشغيل الجزء ) بالكامل لوحدات التحكم/طرق العرض.

لهذا أستخدم المكوّن الإضافي tweaked Rails-authorization-plugin الذي يحتوي على جميع الإمكانيات التي ذكرتها للتو (أنواع مختلفة من الأدوار، والعديد من الأدوار لمستخدم واحد، والترخيص على وحدة التحكم ومستوى العرض).

Answer 2

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

تم وصف موقف/حل مماثل هنا

Answer 3

من بين الاقتراحين، يبدو الخيار الأول أفضل قليلاً لأنه يسمح لك بإضافة إجراءات قد لا تكون إجراءات على مستوى النموذج.أعتقد أنك ستواجه حالة لا يقوم فيها النموذج الثاني بما يكفي، وستحتاج إما إلى تغيير المخطط أو البدء في نشر منطق الأذونات في جميع أنحاء تطبيقك (على سبيل المثال،""المستخدمون الذين ليس لديهم حق الوصول إلى "الإنشاء" لا يمكنهم أيضًا تشغيل الطريقة xxx")

أعتقد أن السبب وراء عدم ظهور الحل جافًا للغاية هو وجود التكرار:

1. في أسماء الأقسام، و
2. في قسم القدرات

فيما يتعلق بالرقم 1، سيكون من المنطقي إنشاء جدول أقسام ومنح كل قسم معرفًا.

أما بالنسبة لرقم 2 فأنا أتفق مع التعليق الأول.ربما يمكنك تجميع وحدات التحكم والإجراءات المختلفة في مجموعات وظيفية، ثم تعيين علاقة كثير إلى كثير (جدول التعيين) بين المستخدمين والوظائف.سيكون للوظائف بعد ذلك علاقة رأس بأطراف مع الإجراءات/وحدات التحكم التي تسمح بها.سيسمح لك ذلك، مع أقل قدر من التكرار، بقول أشياء مثل "يجب أن تكون المحاسبة والمبيعات قادرة على قراءة جميع الجداول المالية".