التفويض

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

نظرة عامة على نموذج التفويض

Four-Layer Security Model:

Layer 1: Authentication
    ↓
 Who you are? (Password, 2FA, OAuth)
    ↓
Layer 2: Admin Rights (Permissive)
    ↓
 What CAN you modify? (usersUpdate, pointsCreate, etc.)
    ↓
Layer 3: Role Restrictions (Restrictive)
    ↓
 What CANNOT you see? (Field filters: owner, status, category)
    ↓
Layer 4: Server-Side Rendering (SSR)
    ↓
 Enforcement at API (unauthorized data never sent to client)

أمن من أربع طبقات: ١. المصادقة - هويتك (تمت تغطيتها في قسم المصادقة) ٢. حقوق الإدارة - ما يمكنك تعديله (منح متساهلة) ٣. قيود الأدوار - ما لا يمكنك رؤيته (مرشحات تقييدية) ٤. التنفيذ من جانب الخادم - البيانات غير موجودة فعليًا للمستخدمين غير المصرح لهم

يوفر هذا النموذج مرونة هائلة مع الحفاظ على الأمان.

حقوق الإدارة (متساهلة)

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

حقوق الإدارة الشائعة:

• usersUpdate - تحرير ملفات تعريف المستخدمين الآخرين (الاسم، اللقب، القسم - وليس البريد الإلكتروني/كلمة المرور)
• usersLogout - فرض تسجيل الخروج أو قفل حسابات المستخدمين
• usersDelete - حذف حسابات المستخدمين
• usersCreate - إنشاء مستخدمين جدد أو استعادة الحسابات المحذوفة
• pointsCreate، pointsUpdate، pointsDelete - تعديل ميزات النقاط
• ordersCreate، ordersUpdate، ordersDelete - إدارة أوامر العمل
• assignmentsCreate - إنشاء مهام العمل
• reportsCreate - إرسال تقارير العمل
• transactionsCreate - إنشاء معاملات المخزون

حقوق فائقة (تتجاوز جميع الحقوق الأخرى):

• appSettingSchemasModify - تعديل إعدادات مستوى التطبيق (المجالات، فترات الانتظار، الأمان)
• adminRightsModify - منح حقوق الإدارة لمستخدمين آخرين
• viewDeleted - عرض السجلات المحذوفة (شبه شاملة، يتم تجاوزها جزئيًا بواسطة قيود الدور)

التحقق من حقوق الإدارة للمستخدم: ١. انتقل إلى الإدارة → المستخدمون ٢. افتح ملف تعريف المستخدم ٣. يسرد قسم "حقوق الإدارة" جميع الأذونات الممنوحة

قيود الأدوار (تقييدية)

صفحة إدارة الأدوار تعرض قيود الأدوار التي تم تكوينها

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

مكونات الدور:**

• الأعضاء - المستخدمون الذين تنطبق عليهم هذه القيود
• المالك - المستخدم الذي يتحكم في العضوية (أو المستخدمون الذين يتمتعون بحق المسؤول rolesUpdate)
• قيود الدور - عوامل تصفية على مستوى الحقل تخفي بيانات محددة

هيكل قيود الدور

صفحة تفاصيل الدور التي تعرض تكوين القيود على مستوى الحقل

يحدد كل قيد ما يلي:

• النموذج - نوع البيانات (النقاط، المضلعات، التخصيصات، إلخ)
• الحقل - الخاصية التي سيتم التصفية بناءً عليها (المالك، الحالة، الفئة، الحقول المخصصة)
• المقارنة - كيفية المطابقة (=، !=، >، <، يحتوي على، إلخ)
• قيمة التصفية - القيمة المطلوب مطابقتها
• الأذونات - ما الذي تم حظره (قراءة، تعديل، إنشاء، حذف)

مثال على حالة الاستخدام: فصل المقاولين

السيناريو: منع المقاول "أ" من رؤية عمل المقاول "ب"

الإعداد: ١. إنشاء دور: "المقاول أ" ٢. إضافة تقييد الدور:

• النموذج: نقطة (ميزات)
• الحقل: المالك
• المقارنة: =
• قيمة التصفية: المقاول ب
• الأذونات: قراءة ✓، تعديل ✓، إنشاء ✓، حذف ✓ (كلها صحيحة = لا يمكن القيام بأي من هذه) ٣. إضافة مستخدمي المقاول أ كأعضاء

النتيجة:

• لا يمكن لأعضاء المقاول أ رؤية أي نقاط حيث المالك = "المقاول ب"
• ليس مجرد إخفاء في واجهة المستخدم - تعيد واجهة برمجة التطبيقات (API) البيانات كما لو أن السجلات غير موجودة
• لا يمكن رؤيتها عن طريق الخطأ عبر لقطة شاشة أو استدعاء واجهة برمجة التطبيقات (API) أو التصدير
• يتم فرضها بالكامل من جانب الخادم

حالات استخدام إضافية

حسب مرحلة العمل: منع العاملين الميدانيين من رؤية تقارير التحقق من الجودة:

Role: "Field Workers"
Restriction:
  Model: Validation
  Field: status
  Comparison: !=
  Filter Value: "" (any value)
  Permissions: Read ✓

لا يمكن للعاملين الميدانيين رؤية عمليات التحقق على الإطلاق.

حسب نوع الأصول: فصل فرق البنية التحتية (الأعمدة/القنوات مقابل المعدات النشطة):

Role: "Civil Team"
Restriction:
  Model: Point
  Field: category
  Comparison: =
  Filter Value: "Active Equipment"
  Permissions: Read ✓, Edit ✓, Create ✓, Delete ✓

لا يمكن لفريق الهندسة المدنية رؤية نقاط المعدات النشطة أو تعديلها.

حسب المادي/المنطقي: فصل الوصول إلى بيانات المكاتب (علاقات السعة مقابل مواقع المكاتب):

Role: "Capacity Analysts"
Restriction:
  Model: Point
  Field: layer
  Comparison: =
  Filter Value: "Office Locations"
  Permissions: Edit ✓, Create ✓, Delete ✓

يمكن للمحللين عرض المكاتب ولكن لا يمكنهم تعديل المواقع (للقراءة فقط).

الجمع بين حقوق الإدارة + قيود الأدوار

السلوك الافتراضي: يمكن لجميع المستخدمين رؤية كل شيء ولكن لا يمكنهم تغيير أي شيء (بدون حقوق الإدارة).

إضافة حق الوصول للكتابة مع قيود:

مثال: يمكن للعاملين الميدانيين تعديل أعمالهم الخاصة ولكن لا يمكنهم تعديل أعمال الآخرين

Admin Rights:
  - reportsCreate: true
  - reportsUpdate: true

Role Restrictions:
  Model: Report
  Field: reportedBy
  Comparison: !=
  Filter Value: [current user ID]
  Permissions: Edit ✓

النتيجة:

• يمكن للعاملين إنشاء تقارير (تم منح حق الإدارة)
• يمكن للعاملين تعديل تقاريرهم الخاصة فقط (تقوم قيود الدور باستبعاد الآخرين)
• لا يمكنهم رؤية أو تعديل تقارير العاملين الآخرين

التنفيذ من جانب الخادم (SSR)

كيفية العمل:

• يتم تصفية جميع استعلامات واجهة برمجة التطبيقات (API) قبل البحث في قاعدة البيانات
• يتم تطبيق قيود الأدوار من جانب الخادم (وليس مجرد إخفاء واجهة المستخدم)
• لا يمكن للمستخدم التجاوز عبر استدعاءات واجهة برمجة التطبيقات (API) المباشرة أو أدوات المتصفح أو عمليات التصدير
• البيانات غير موجودة فعليًا للمستخدمين غير المصرح لهم

مثال على الاستعلام:

User requests: GET /api/points

Without restrictions:
  SELECT * FROM points WHERE deletedAt IS NULL

With role restriction (owner != "Contractor B"):
  SELECT * FROM points 
  WHERE deletedAt IS NULL 
  AND (owner IS NULL OR owner != "Contractor B")

الآثار الأمنية:

• لن تساعدك لقطة شاشة لشاشة شخص آخر (لن يتم تحميل البيانات لك)
• لا يمكن تصدير البيانات المقيدة (تفرض واجهة برمجة التطبيقات (API) الفلاتر)
• لا يمكن "تخمين" معرّفات السجلات (يتم تصفية قبل البحث عن المعرّف)
• حتى إذا رأى المهاجم معرّف السجل في حركة مرور الشبكة، فإن عملية الاسترداد تعود بـ ٤٠٤

إدارة الأدوار

إنشاء الأدوار: ١. انتقل إلى الإدارة → الأدوار ٢. انقر على "إنشاء دور" ٣. أدخل اسم الدور ووصفه ٤. أضف الأعضاء (اسحب المستخدمين إلى حقل الأعضاء) ٥. أضف قيود الدور (يمكن أن يكون هناك أكثر من واحدة) ٦. حفظ

تحرير الأدوار:

• فقط مالك الدور أو المستخدمون الذين لديهم حق الإدارة rolesUpdate
• يمكن إضافة/إزالة الأعضاء
• يمكن تعديل القيود
• يمكن حذف الدور (تحرير الأعضاء من القيود)

عضوية الدور:

• يمكن للمستخدمين أن يكونوا في أدوار متعددة (تُجمع القيود)
• مغادرة المؤسسة: إزالة من جميع الأدوار قبل حذف الحساب
• العضوية الجماعية: سحب عدة مستخدمين دفعة واحدة

تخصيص التفويض للمستخدمين الجدد

تكوين إعدادات التطبيق (يتطلب appSettingSchemasModify): ١. انتقل إلى إعدادات التطبيق → المصادقة ٢. "أدوار للمستخدمين الجدد" - تعيين الأدوار تلقائيًا للحسابات الجديدة ٣. "حقوق الإدارة للمستخدمين الجدد" - منح الأذونات الافتراضية ٤. حفظ

التكوينات النموذجية:

الإعدادات الافتراضية للعامل الميداني:

Roles: ["Field Workers"]
Admin Rights: {
  reportsCreate: true,
  assignmentsRead: true
}

الإعدادات الافتراضية لمنسق المكتب:

Roles: []
Admin Rights: {
  assignmentsCreate: true,
  ordersCreate: true,
  stockItemsView: true
}

لا منح تلقائي (مراجعة يدوية):

Roles: []
Admin Rights: {} (none)

يقوم المسؤولون بالتعيين يدويًا بعد مراجعة الحساب.

عرض الأذونات السارية

لمستخدم معين: ١. انتقل إلى ملف تعريف المستخدم ٢. قسم "حقوق المسؤول" - ما يمكنهم فعله ٣. قسم "الأدوار" - ما لا يمكنهم رؤيته (عبر القيود) ٤. يعرض العرض المدمج الأذونات السارية

اختبار الأذونات: ١. قم بتسجيل الدخول كمستخدم (أو انتحل شخصية المستخدم باستخدام أذونات المسؤول) ٢. تصفح بشكل طبيعي ٣. البيانات المقيدة ببساطة لا تظهر ٤. الإجراءات التي تتطلب أذونات المسؤول معطلة/مخفية

أفضل الممارسات

ابدأ بالتقييد، ومنح الأذونات حسب الحاجة:

• يحصل المستخدمون الجدد على أذونات محدودة
• أضف أذونات المسؤول حسب متطلبات الأدوار
• منح الأذونات أسهل من إلغائها (يتجنب "تجاوز الأذونات")

استخدام الأدوار لرؤية البيانات:

• فصل المتعاقدين (لمنع استخبارات المنافسة)
• فصل مراحل العمل (مراقبة الجودة عن العاملين الميدانيين)
• فصل أنواع الأصول (البنية التحتية عن المعدات العاملة)

استخدام حقوق الإدارة للقدرات:

• من يمكنه إنشاء المهام
• من يمكنه تعديل المخزون
• من يمكنه منح الأذونات

توثيق الغرض من الدور:

• اسم دور واضح ("المقاول أ" أفضل من "الدور ١")
• الوصف يشرح القيود
• يساعد المسؤولين المستقبليين على فهم المقصد

تدقيقات منتظمة للأذونات:

• مراجعة ربع سنوية لحقوق المسؤولية الخاصة بالمستخدم
• إزالة الحقوق غير المستخدمة (تغيير أدوار المستخدم)
• التحقق من عضويات الأدوار (المستخدمون الذين غادروا المؤسسة)

مراقبة محاولات الوصول:

• تسجيل محاولات التفويض الفاشلة
• نمط الرفض = محاولة المستخدم الوصول غير المصرح به
• التحقيق وتعديل الأذونات أو توعية المستخدم

مبدأ أقل الامتيازات:

• منح الحد الأدنى من الأذونات المطلوبة لأداء الوظيفة
• وصول مؤقت بامتيازات أعلى للمشاريع (إزالته بعد ذلك)
• حقوق فائقة (adminRightsModify) للمسؤولين الموثوق بهم فقط