"لذا ... أحتاج إلى إذن بسيط. نوع من دور المشرف ، وربما دور المحرر / المشرف. الآن جوجل. أوه! هناك بالفعل مجموعات جاهزة للارافيل!
zizaco / عهد ،
spatie / laravel- إذن وغيرها! دعنا نختار بعض! "
هكذا يحدث كل شيء. ثم يضيف ترحيل الحزمة 5 تصنيفات إلى قاعدة البيانات لتخزين الأدوار والأذونات وعلاقاتها. يتم تخزين جميع قواعد التفويض ، مثل الأدوار
'admin' و
'editor' ، 'تحرير المنشورات' ، في هذه الجداول. عادة ، يحتوي المشروع على العديد من النسخ من قاعدة البيانات. نسخ من المطورين وقاعدة (قواعد) الإنتاج. ونتيجة لذلك ، تضطر جميع قواعد التفويض هذه إلى المزامنة بين قواعد البيانات.
التقيت ببعض المشاريع حيث كانت هناك نسخة رئيسية واحدة من القواعد في قاعدة بيانات الإنتاج والباقي نسخ كل شيء من هناك.
فكرة استخدام فئة Seeder (
مثال ) أفضل بكثير. تحتاج فقط إلى الجري
php artisan db:seed AuthSeeder
ولديك أحدث نسخة من القواعد في قاعدة البيانات. وهكذا ، تصبح هذه الفئة البذرية نوعًا من مصدر واحد للحقيقة. جيد ، ولكن لا يزال هناك العديد من المضايقات في هذا النهج:
- يجب أن يكون Seeder ذكيًا بما يكفي ليس فقط لإنشاء الأدوار والأذونات والاتصالات بينهما ، ولكن أيضًا لمزامنة الإصدارات القديمة. على سبيل المثال إزالة أو إنشاء روابط بين الأدوار والأذونات إذا لزم الأمر.
- يتم تخزين القواعد في قاعدة البيانات والمزامنة المستمرة بينهما. كل تغيير في متطلب النموذج "يجب على المحررين عدم تحرير المنشورات ، نشرها فقط" يؤدي إلى تغيير في البذرة ، ومزامنة قاعدة التعليمات البرمجية من خلال بوابة أو شيء ما ، و "لا تنس أن تبدأ AuthSeeder!"
- يمكن أن تكون قواعد التفويض معقدة. على سبيل المثال ، يمكن تحرير المنشور ليس فقط بواسطة المحررين أو المسؤولين ، ولكن أيضًا بواسطة مؤلف هذا المنشور. لذلك ، بدلاً من البرامج الوسيطة البسيطة:
['middleware' => ['permission:edit posts']]
يجب على المطورين استخدام إذن Laravel القياسي:
class PostPolicy { public function edit(User $user, Post $post) { return $user->id == $post->owner_id || $user->hasPermissionTo('edit posts'); } }
لذا ربما أسهل طريقة ليست الأفضل؟
يبدو الأمر بسيطًا: ضع الحزمة وشغّل الترحيل النهائي وانطلق. من وجهة نظر دعم المشروع على المدى الطويل ، ليس هذا هو الخيار الأفضل.
دعونا نحاول تحليل ما تحتاجه المشاريع عادة؟ نظام لعب أدوار بسيط. دائما دور واحد لكل مستخدم. المسؤول حسنًا ، ربما محرر أو مشرف آخر. وهذه الأدوار لها بعض الأذونات. دعنا نذهب بأكثر طريقة مباشرة! إضافة حقل جديد إلى جدول المستخدمين!
is_admin أو
دور . ثم قام مساعدان لفئة
المستخدم :
class User { public function isAdmin(): bool {...} public function isEditor(): bool {...} }
تصرخ الآن. يوفر Laravel طريقتين أساسيتين لوصفهما:
البوابات والسياسات . سأستخدم البوابات (لا تزال هناك خدعة صغيرة مع وظيفة في متغير ، ولكن لعشاق البرمجة الوظيفية هذه ليست خدعة على الإطلاق):
$isAdmin = function (User $user) { return $user->isAdmin(); } $isEditorOrAdmin = function (User $user) { return $user->isAdmin() || $user->isEditor(); } Gate::define('foo-permission', $isAdmin); Gate::define('bar-permission', $isAdmin); Gate::define('editor-permission', $isEditorOrAdmin);
إذا كان المشروع يحتاج إلى عدة أدوار لكل مستخدم ،
فما عليك سوى إضافة جدول
user_roles وتغيير مساعدي فئة
المستخدم . محتويات فئة البذرة لحزم * الثقة وهذا التفويض المستند إلى التعليمات البرمجية متطابقان تقريبًا! ولكن يتم الآن تخزين القواعد ببساطة في التعليمات البرمجية وليس هناك حاجة لمزامنتها باستمرار في قواعد البيانات.
لا أريد أن أقول إن هذه الحزم عديمة الفائدة. يعد هذا النهج مفيدًا جدًا في المشاريع التي تحتوي على نظام تفويض معقد ، حيث يريد العميل نفسه تكوين الأدوار لاحقًا. هناك أيضًا مشروعات ذات أذونات ديناميكية. مثال: منتدى مع المنتديات الفرعية. يمكن أن يكون لكل منتدى فرعي مشرفين خاصين به ، ولكل مشرف حقوق يحددها المسؤول في هذا المنتدى الفرعي. مثال آخر هو برقية ومجموعاتها. هناك نفس الشيء. تحتاج مثل هذه المشاريع بالفعل إلى نظام معقد ومخزن في قاعدة البيانات ونظام التفويض مع جميع مشاكله. لكن معظم الآخرين لا يفعلون ذلك.
يصبح الوضع مع حزم لارافيل مشابهًا للحالة مع مكونات دلفي (يتذكر كبار السن). لقد وضعوا الطرود دون تردد - حقًا أم لا.
لذا ، سيكون عليّ حساب $ a + $ b في مشروعي هنا. هل هناك أي حزمة لارفل مبلغ؟
PS أعتذر عن الأذونات ، لكنني لم أجد ترجمة دقيقة جيدة.