استخدام اكثر من Firewall في Symfony

Symfony > استخدام اكثر من Firewall في Symfony

لم يتم التحقق من صحة ما ورد في هذه الصفحه لهذا فانها تعتبر غير مكتملة ولا يمكن الاعتماد على ما ورد فيها

وضحت في بحثي السابق "Authentication و Authorization في Symfony" اننا نقوم بانشاء Firewall من اجل حماية URL pattern بنظام تسجيل دخول حيث انني قمت على حماية حمايه /backend بواسطه Firewall باسم main يستخدم Admin Entity من اجل طلب تسجيل الدخول لاي زائر للتطبيق يقوم بالدخول الى /backend ويجب ان يكون الدخول صحيح والمستخدم مسجل مسبقا في جدول admin في قاعدة البيانات. ولكن ما سوف اناقشه اليوم ماذا لو كان لدي URL pattren اخر اود حمايتها بنموذح تسجيل دخول اخر يستمد معلومات تسجيل الدخول من جدول اخر في قاعدة البيانات . على سبيل المثال اود حماية /Users بنموذج تسجيل دخول يعتمد على المستخدمين المسجلين في جدول user في قاعدة البيانات مع الابقاء على /backend محمية بنموذج تسجيل الدخول الذي يعتمد على المستخدمين المسجلين في جدول admin.

ملاحظه: انا اعرف انه من غير المنطقي ان يكون هناك نظام دخول ل Admin منفصل عن نظام دخول ال User في نظام يعتمد على مبدا الصلاحيات roles اذ انه يمكن ان يكون نفس النظام مع تحديد صلاحيات Admin وتحديد صلاحيات User ، ولكن انا في مثالي هذا فقط احاول توضيح كيفية استخدام اكثر من Firewall في Symfony لهذا فقد استخدمت فكرة Admin و User للتبسيط.

لماذا نحتاج إلى استخدام جدران حماية متعددة في Symfony أحيانا؟

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

1. آليات مصادقة مختلفة:

قد تتطلب أجزاء مختلفة من التطبيق طرق مصادقة مختلفة. على سبيل المثال:

• قسم الإدارة قد يستخدم مصادقة باسم المستخدم وكلمة المرور.
• واجهة برمجة التطبيقات (API) قد تستخدم مصادقة قائمة على الرموز (tokens).

استخدام جدران حماية متعددة يسمح لك بتكوين طرق المصادقة المختلفة بشكل منفصل.

2. تأمين أنماط URL مختلفة:

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

• /admin/* يجب أن يكون الوصول إليها مقتصرا على المستخدمين الإداريين.
• /api/* يجب أن تستخدم سياق أمان مختلف وآلية مصادقة مختلفة.

جدران الحماية المتعددة تتيح لك تطبيق قواعد أمان مختلفة على أنماط URL مختلفة.

3. تبديل السياقات

في بعض الحالات، قد تحتاج إلى تبديل سياقات الأمان داخل نفس التطبيق. على سبيل المثال:

• يمكن للمستخدم أن يتم مصادقته بشكل عادي على الموقع.
• قد يحتاج نفس المستخدم إلى مصادقة مختلفة عند الوصول إلى خدمة أو قسم معين في الموقع.

جدران الحماية المتعددة يمكن أن تساعد في إدارة هذه التحويلات السياقية بفعالية.

استخدام اكثر من Firewall

من اجل توفير الكود الذي سوف اقوم على كتابته في هذا البحث على الانترنت وارشفته وجعلة متاحا للجميع فانني قمت على انشاء مستودع على GitHub ضمن برانش (branch) خاص يمكنك الوصول اليه والاطلاع على الاكواد على الرابط https://github.com/mshannaq/symfony-access-control-research/tree/multiple-firewalls، هذا البرانش ماخوذ من برانش symfony-access-control-research الذي قمت بانشاءه عند حديثي عن Authentication و Authorization في Symfony و ارجو العلم ان المشروع الموجود في مستودع Github هو للاغراض التعليمية فقط.

لهذا فانني لاستخدام اكثر من Firewall سوف اقوم على التالي:

1. انشاء اكثر من URL من اجل حمايته واحد /backend والاخر /users .
2. التاكد من انشاء كلاس Admin و User بحيث يكون كل كلاس مسؤول عن تسجيل الدخول لكل فئه والتاكد من انشاء Entity لكل من Admin و User وانشاء migration file وتطبيق التعديلات على القاعدة.
3. التاكد من توفر امر console لاضافه Admin واضافه User.
4. التاكد من انشاء Controller المسؤول عن Admin و Controller مسؤول عن User وضبط اعدادات ال Firewall من خلال ملف config/packages/security.yaml

انشاء اكثر من Firewall في Symfony

آولا: انشاء اكثر من URL من اجل حمايته واحد /backend والاخر /users .

كون ملفات المشروع مآخوذه من برانش symfony-access-control-research فان Controller Backend موجود مسبقا لهذا فانني فقط سوف اقوم على انشاء Controller جديد باسم Users من خلال تنفيد الامر

php bin/console make:controller Users

> راجع التعديلات التي تمت على الرابط التالي.

ثانيا: التاكد من انشاء كلاس Admin و User بحيث يكون كل كلاس مسؤول عن تسجيل الدخول لكل فئه والتاكد من انشاء Entity لكل من Admin و User وانشاء migration file وتطبيق التعديلات على القاعدة.

كون ملفات المشروع مآخوذه من برانش symfony-access-control-research فان كلاس Admin موجوده مسبقا لهذا فانني سوف اقوم بانشاء كلاس User وللقيام بذلك سوف اقوم على تنفيد الامر التالي:

php bin/console make:user

واجابتي على الاسئلة سوف تكون كالتالي:

The name of the security user class (e.g. User) [User]:
 > User

 Do you want to store user data in the database (via Doctrine)? (yes/no) [yes]:
 > yes

 Enter a property name that will be the unique "display" name for the user (e.g. email, username, uuid) [email]:
 > username

 Will this app need to hash/check user passwords? Choose No if passwords are not needed or will be checked/hashed by some other system (e.g. a single sign-on server).

 Does this app need to hash/check user passwords? (yes/no) [yes]:
 > yes

 created: src/Entity/User.php
 created: src/Repository/UserRepository.php
 updated: src/Entity/User.php
 updated: config/packages/security.yaml


  Success!


 Next Steps:
   - Review your new App\Entity\User class.
   - Use make:entity to add more fields to your User entity and then run make:migration.
   - Create a way to authenticate! See https://symfony.com/doc/current/security.html

> راجع التعديلات والاضافات التي تمت على الرابط التالي. الان لانشاء migration file للتعديلات الجديده نقوم بتنفيذ الامر

php bin/console make:migration --formatted

ومن ثم لتطبيق التعديلات على قاعدة البيانات نقوم على تنفيذ الامر

php bin/console doctrine:migrations:migrate

بامكانك التحقق من قاعدة البيانات للتاكد من انشاء جدول باسم user وهو الجدول الذي سوف يحتوي على المستخدمين المصرح لهم

> راجع التعديلات التي تمت على الرابط التالي.