MySQL - هيكل للأذونات للأشياء

Question

ما هو بنية مثالية للمستخدمين> أذونات الكائنات.

لقد رأيت العديد من المنشورات ذات الصلة للأذونات العامة ، أو ما هي الأقسام التي يمكن للمستخدم الوصول إليها ، والتي تتكون من أ users, userGroups و userGroupRelations أو شيء من هذا القبيل.

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

Group 1
    Group 2
    Group 3
    Group 4
Group 5
   Group 6
Group 7
   Group 8
       Group 9
       Group 10

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

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

فكرتي الحالية هي أن يكون لديك جدول مستخدمين ، ثم جدول أذونات مع أعمدة مثل:

permission_id (int) PRIMARY_KEY
user_id (int) INDEX
object_id (int) INDEX
type (varchar) INDEX
admin (bool)
read (bool)
write (bool)
edit (bool)
delete (bool)

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

سيكون هناك جدول منفصل لأدوار المستخدمين/المشرفين ، مما يعني أنه يمكنهم تغيير الأذونات على المستخدمين أدناه للمجموعات التي يمكنهم التحكم فيها.

لذلك ، كأسئلة ، هل يجب أن أستخدم الهيكل أعلاه؟ أو هل يمكن لأي شخص أن يوجهني في اتجاه واحد أفضل؟

---

تعديل

البديل هو إنشاء جدول إذن لكل نوع من الكائنات.

Answer 1

أقترح عليك إضافة طابع زمني "last_update" وعمود "last_updated_by_user" بحيث يكون لديك بعض الأمل في تتبع التغييرات في هذا الجدول في نظام التشغيل الخاص بك.

يمكنك التفكير في إضافة إذن - منحة. سيتمكن المستخدم من منح المنحة لكائن ما من منح الوصول إلى المستخدمين الآخرين إلى الكائن المعني.

كن حذرًا مع "الاحتياجات إلى التوسع بسرعة". من الصعب تخمين دون تجربة إنتاج العالم الحقيقي الذي يحتاجه نظام التحجيم حقًا.

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

يبدو أن مخططك يربط المستخدمين بالأشياء. هل تريد أن يكون المفتاح الأساسي الخاص بك وفهرسك الفريد (user_id ، object_id)؟ وهذا هو ، هل تريد أن يكون لكل مستخدم إما صفر أو إدخال إذن واحد لكل كائن؟ إذا كان الأمر كذلك ، فاستخدم المفتاح الأساسي لفرض ذلك ، بدلاً من استخدام مفتاح Serrogate Semission_ID الذي تقترحه.

بالنسبة لكائناتك الموجودة في التسلسلات الهرمية ، يجب عليك جعل أحد خيارين على مستوى النظام:

1. تمنح منحة إلى كائن مع المشروعات الفرعية ضمنيًا الوصول إلى الكائن فقط ، أو ...

2. كما أنه يمنح الوصول إلى جميع المشروعات الفرعية.

يقلل الخيار الثاني من عبء منح الإذن الصريح عند إنشاء المشروعات الفرعية الجديدة. الخيار الأول أكثر أمانًا.

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

أعتقد أن الخيار الأول ربما يكون متفوقًا. أقترح تخطيط الجدول هذا:

user_id (int)
object_id (int)
type (varchar)  (not sure what you have this column for)
admin (bool)
read (bool)
write (bool)
edit (bool)
grant (bool)
delete (bool)
last_update (timestamp)
last_updated_by_user_id (int)
primary key = user_id, object_id.

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

user_id (int)
object_id (int)
permission_enum (admin/read/write/edit/grant/delete)
type (varchar)  (not sure what you have this column for)
last_update (timestamp)
last_updated_by_user_id (int)
primary key = user_id, object_id, permission_enum