إتقان التحكم في الوصول المبني على الدور في Logto: مثال واقعي شامل

المقدمة#

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

من خلال فحص شفرات البرمجة الأمامية والخلفية، ستكتسب منظورًا شاملاً حول دمج نظام RBAC الخاص بـ Logto في مجموعة تطبيقاتك. بنهاية هذه المقالة، ستكون مجهزًا بشكل جيد لاستخدام ميزات RBAC لـ Logto لتعزيز أمان مشروعك والتحكم في الوصول.

تقديم BookHarber: حالة استخدام مكتبة إلكترونية#

لتوضيح ميزات RBAC الخاصة بـ Logto بشكل فعال، سنستخدم مثالًا واقعيًا: BookHarber، مكتبة إلكترونية. تقدم BookHarber مجموعة واسعة من الميزات للعملاء والموظفين، مما يضمن تجربة تسوق سلسة وآمنة.

الميزات الرئيسية لـ BookHarber تشمل:

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

الأدوار#

في نظام BookHarber، يمكننا تحديد عدة أدوار مستخدمين رئيسية، مثل:

1. الضيف: المستخدمون غير المسجلين الذين يمكنهم تصفح الموقع، والبحث عن الكتب، ومشاهدة العروض الخاصة.
2. العميل: المستخدمون المسجلون الذين يمكنهم شراء الكتب، وإدارة الطلبات، وتتبع اللوجستيات، وفتح تذاكر الدعم.
3. مدير المتجر: موظفون مسؤولون عن الإشراف على الإدارة العامة وعمليات المنصة. مع وصول كامل.
4. مدير الكتب: موظفون مسؤولون عن إدارة الكتب والفئات.
5. وكيل خدمة العملاء: موظفون مكلفون بالرد على تذاكر الدعم.
6. مزود اللوجستيات من الطرف الثالث: شركاء خارجيون مسؤولون عن إدارة وتتبع شحن وتسليم الطلبات.
7. طاقم التسويق: موظفون مسؤولون عن الترويج لـ BookHarber، مسؤولون عن إدارة العروض الخاصة والفعاليات.

تصميم النطاقات لـ REST APIs لـ BookHarber#

لتنفيذ نظام RBAC الخاص بـ Logto لـ BookHarber بفعالية، نحتاج إلى تصميم نطاقات تتوافق مع مختلف REST APIs. النطاقات هي الأذونات التي تحدد مستوى الوصول الذي يمتلكه دور معين لكل نقطة نهاية API. عن طريق تعيين النطاقات المناسبة لكل دور مستخدم، يمكننا ضمان أن يكون لدى المستخدمين الوصول فقط إلى الإجراءات والموارد ذات الصلة بدورهم.

لنقم بتصميم النطاقات للـ REST APIs التالية:

1. Categories API:
   • create:categories: POST /categories
   • write:categories: PUT /categories/:id
   • delete:categories: DELETE /categories/:id
   • list:categories: GET /categories
2. Books API:
   • create:books: POST /books
   • write:books: PUT /books/:id
   • delete:books: DELETE /books/:id
   • list:books: GET /books
   • read:books: GET /books/:id
3. Customers API:
   • list:customers: GET /customers
   • write:customers: PUT /customers/:id
   • delete:customers: DELETE /customers/:id
   • read:customers: GET /customers/:id
4. Orders API:
   • create:orders: POST /orders
   • list:orders: GET /orders
   • read:orders: GET /orders/:id
   • write:orders: PUT /orders/:id
5. Events API:
   • create:events: POST /events
   • write:events: PUT /events/:id
   • list:events: GET /events
   • delete:events: DELETE /events/:id
6. Order Tracks API:
   • read:orderTracks: GET /orders/:id/tracks
   • create:orderTracks: POST /orders/:id/tracks
   • write:orderTracks: PUT /orders/:id/tracks/:trackId
7. Tickets API:
   • create:tickets: POST /tickets
   • list:tickets: GET /tickets
   • read:tickets: GET /tickets/:id
   • write:tickets: PUT /tickets/:id

تعيين النطاقات إلى الأدوار#

الآن وقد حددنا النطاقات المناسبة لكل REST API، يمكننا تعيين هذه النطاقات إلى أدوار المستخدمين المعنية في نظام BookHarber:

فهم الفروقات بين نطاقات "list" و"read"#

لتوضيح الفروقات بين نطاقات "list" و"read" في سياق تصميم REST API و RBAC، دعنا نفكر في مثال واقعي يشمل مكتبة إلكترونية، BookHarber.

افترض أن BookHarber لديها نوعان من المستخدمين: العملاء ووكلاء خدمة العملاء. يمكن للعملاء إنشاء الطلبات، بينما يكون وكلاء خدمة العملاء مسؤولين عن مساعدة العملاء في طلباتهم. لنلق نظرة على كيفية تطبيق نطاقات "list" و"read" على مورد orders API في هذا السيناريو.

1. نطاقات القائمة: يسمح نطاق "list" للمستخدم بالوصول إلى مجموعة من الكيانات في النظام. على سبيل المثال، نطاق list:orders يتيح للمستخدم استرجاع قائمة بجميع الطلبات المتاحة. في سياق BookHarber، يمكن أن يكون هذا النطاق مفيدًا لمسؤولي المتجر أو الموظفين الآخرين الذين يحتاجون إلى الحصول على لمحة عامة عن جميع الطلبات في النظام. ومع ذلك، لا ينبغي أن يكون وكلاء خدمة العملاء قادرين على الوصول إلى القائمة الكاملة للطلبات، حيث أن دورهم هو مساعدة العملاء الأفراد في طلباتهم المحددة.
2. نطاقات القراءة: يمنح نطاق "read" المستخدم إذنًا للوصول إلى كيان واحد باستخدام معرف معين. على سبيل المثال، نطاق read:orders يتيح للمستخدم عرض معلومات تفصيلية حول طلب معين بواسطة معرفه. في حالة BookHarber، يكون هذا النطاق مثاليًا لوكلاء خدمة العملاء الذين يحتاجون إلى الوصول إلى معلومات حول طلب عميل معين. عندما يفتح عميل تذكرة دعم، يمكن لوكيل خدمة العملاء استخدام معرف الطلب المقدم في التذكرة للوصول وعرض تفاصيل هذا الطلب المحدد.

فهم الملكية: لماذا لا يحتاج العملاء إلى نطاقات "read" أو "list" لأوامرهم الخاصة#

في العديد من التطبيقات، من الشائع أن يكون لدى المستخدمين وصول إلى مواردهم الخاصة دون منحهم صراحة النطاقات المقابلة لـ "read" أو "list". ذلك لأن المستخدمين يعتبرون مالكين لهذه الموارد ويجب أن يحصلوا على حق الوصول إليها بشكل طبيعي. في حالة مثال BookHarber لدينا، يمكن للعملاء إنشاء الطلبات لكنهم لا يمتلكون نطاقات "read:orders" أو "list:orders".

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

لتوضيح كيف يعمل هذا، فلننظر في نقطة النهاية GET /orders:

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

عبر تنفيذ هذا التحكم في الوصول المستند إلى الملكية، يمكن لـ API توفير مستوى مناسب من الوصول لأدوار المستخدم المختلفة مع الحفاظ على الأمان وتوفير تجربة مستخدم مخصصة. في سيناريو BookHarber، يسمح نموذج الملكية للعملاء بالوصول إلى معلومات طلباتهم بدون الحاجة إلى نطاقات "read:orders" أو "list:orders"، مما يبسط تصميم التحكم في الوصول ويعزز من تجربة المستخدم العامة.

تكوين الإعدادات في Logto Console#

لإكمال التكوين في Logto Console، اتبع هذه الخطوات:

1. إنشاء تطبيق صفحة واحدة (SPA) لـ React: إنشاء SPA في Logto Console لتطبيقات الـ React الخاصة بك.
2. إنشاء مورد API: إضافة مورد API جديد مع المعرف https://api.bookharber.com.
3. تعريف النطاقات للمورد: إنشاء النطاقات اللازمة ضمن مورد API الذي تم إنشاؤه حديثًا.
4. إنشاء الأدوار وتعيين النطاقات: تعريف أدوار المستخدمين لتطبيقك، وتعيين النطاقات المناسبة لكل دور.
5. تعيين الأدوار للمستخدمين: تعيين الأدوار ذات الصلة للمستخدمين في تطبيقك، والتأكد من أن كل مستخدم (خاصة أعضاء الفريق) لديه الأذونات الصحيحة بناءً على دوره.

حماية API باستخدام النطاقات#

في مشروع المثال لدينا، BookHarber، نستخدم Express للخدمة الخلفية و React لصفحة الويب الواجهة الأمامية. يقدم هذا القسم لمحة عامة موجزة حول كيفية تكامل ميزات RBAC الخاصة بـ Logto في هذه التقنيات الشهيرة لتأمين تطبيقنا.

المستند الكامل: https://docs.logto.io/docs/recipes/rbac/protect-resource

الواجهة الأمامية#

لتثبيت Logto في تطبيق React الخاص بك، اتبع الوثائق المقدمة هنا: https://docs.logto.io/docs/recipes/integrate-logto/react/

بالإضافة إلى الإعداد الأساسي، ستحتاج إلى تحديد "المورد" و"النطاقات" في التكوين:

إليك مثال لكيفية إجراء طلب API باستخدام Logto:

الواجهة الخلفية#

لحماية API، اتبع: https://docs.logto.io/docs/recipes/protect-your-api/

بالإضافة إلى شفرات البرمجة المقدمة في المثال (https://docs.logto.io/docs/recipes/protect-your-api/node)، سنحتاج إلى إضافة التحقق من النطاق:

الخاتمة#

نظام التحكم في الوصول المبني على الدور لـ Logto هو أداة قوية لإدارة التحكم في الوصول والأمان في التطبيقات الحديثة. عبر استغلال ميزات RBAC لـ Logto، يمكن أن تضمن أن يكون لدى المستخدمين الوصول المناسب إلى الموارد بناءً على أدوارهم، وحماية البيانات الحساسة والوظائف من الوصول غير المصرح به.

في هذه المقالة، استعرضنا مثالًا واقعيًا لمكتبة إلكترونية، BookHarber، وأظهرنا كيفية تصميم النطاقات، وتعيينها لأدوار المستخدمين، وتنفيذ ميزات RBAC لـ Logto في كل من الواجهة الأمامية والخلفية للتطبيق.

بتطبيق هذه المفاهيم والتقنيات في مشاريعك، يمكنك تعزيز الأمان والتحكم في الوصول في تطبيقاتك، وتوفير تجربة مستخدم سلسة وآمنة. سواء كنت تعمل على منصة للتجارة الإلكترونية، أو نظام إدارة محتوى، أو أي مشروع آخر يتطلب التحكم في الوصول المبني على الدور، فإن نظام RBAC لـ Logto يقدم حلًا مرنًا وفعالًا لتلبية احتياجاتك في التحكم في الوصول.