تدفقات المصادقة والحواجز الأمنية

تقوم Kononia بتفويض المصادقة إلى Supabase Auth وتطبق حراس توجيه صارمين من جانب العميل لضمان عزل البيانات وأمانها.

1. طرق المصادقة

البريد الإلكتروني وكلمة المرور: تسجيل الدخول وتسجيل الدخول القياسي. تتطلب رسائل البريد الإلكتروني التحقق إذا تم تمكينها في إعدادات موفر Supabase.
Google OAuth: موفر هوية متحد لجهة خارجية. يتم التكامل تلقائيًا، وإدراج ملف تعريف جديد في قاعدة البيانات عند أول عملية تحقق ناجحة.
استعادة الجلسة: تتم معالجتها تلقائيًا عبر supabase.auth.onAuthStateChange في AuthContext.tsx.

2. إدارة النظام الأساسي مقابل المستخدمين المستأجرين

إدارة النظام الأساسي: الوصول إلى /platform يقتصر بشكل صارم على رسائل البريد الإلكتروني المسجلة في جدول platform.platform_admins.
منع التسجيل المزدوج: يعمل المشغل (block_tenant_signup_for_platform_admin) على منع رسائل البريد الإلكتروني الخاصة بمسؤول النظام الأساسي من التسجيل كمستخدمين مستأجرين قياسيين في المؤسسات العامة، مما يحمي بيانات الاعتماد الإدارية.

3. نظام الدعوة (`الدعوات_المعلقة`)

عندما يقوم مسؤول الكنيسة بتسجيل مستخدم أو عضو جديد، يمكنه إرسال دعوة.

مخطط تسلسل
    المشرف المشارك كمشرف الكنيسة
    قاعدة بيانات المشاركين كقاعدة بيانات Postgres
    المستخدم المشارك كمستخدم مدعو
    المشرف->>DB: إدراج دعوة (البريد الإلكتروني، الدور، person_id)
    المستخدم->>DB: تسجيل الحساب عبر /auth
    DB->>DB: مطالبات بدعوة البريد الإلكتروني المطابق (المطالبات = صحيح)
    DB->>DB: يربط المستخدم بالمؤسسة والأدوار
    المستخدم->>قاعدة البيانات: يصل إلى لوحة تحكم المؤسسة

منطق المطالبة

دعوة البذور: يقوم المسؤول بإنشاء سجل في public.pending_invites يحتوي على البريد الإلكتروني المستهدف، وperson_id الهدف في CRM، ودور النظام الأساسي المعين.
ارتباط التسجيل: عندما يقوم مستخدم جديد بالتسجيل باستخدام البريد الإلكتروني المطابق، يتحقق العميل من الدعوات المعلقة بحثًا عن المطالبات غير المجمعة (المطالبة = خطأ).
دقة التنشيط: عند المطابقة، يقوم النظام بما يلي:
- تحديث حالة الدعوة إلى “المطالبة = صحيح”.
- يربط profiles.organization_id بالمؤسسة الداعية.
- يربط معرف مستخدم المصادقة بـ “people.linked_user_id” الخاص بإدارة علاقات العملاء (CRM).
- يُدرج الأدوار المقابلة في public.user_church_roles.

4. حراس طريق الواجهة الأمامية

لفرض الإعدادات المنطقية، يقوم تطبيق React بتغليف التسلسلات الهرمية للمسار داخل حراس الحماية المخصصة:

[الطريق العام](/auth، /نسيت كلمة المرور، /إعادة تعيين كلمة المرور)
       │
       ▼ (تمت مصادقة المستخدم بنجاح)
[غلاف المسار المحمي]
       │
       ├──► WelcomeGuard (يتحقق مما إذا كانت Profiles.organization_id فارغة)
       │ │
       │ └──► نعم: يعيد توجيه المستخدم إلى /welcome (فرض إعداد المؤسسة)
       │
       └──► OnboardingGuard (يتحقق مما إذا كانت Profiles.has_onboarded خاطئة)
                 │
                 └──► نعم: يعيد توجيه المستخدم إلى /onboarding (فرض إكمال ملف التعريف)

ProtectedRoute: رفض الجلسات غير المصادق عليها، مما يؤدي إلى إرجاع الزائرين إلى /auth.
WelcomeGuard: يقوم بتقييم ما إذا كان ملف التعريف المصادق عليه يحتوي على مؤسسة مرتبطة أم لا. إذا كان organization_id فارغًا، فسيتم إعادة توجيه المستخدم إلى /welcome لإنشاء كنيسة أو الانضمام إليها.
OnboardingGuard: يقوم بتقييم علامة has_onboarded في الملفات الشخصية. إذا كان خطأ، فسيتم توجيه المستخدم إلى /onboarding لملء بيانات السيرة الذاتية الأساسية.