الاصطلاحات المشتركة

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

Identity casing

القاعدة: خزّن كل نصوص الهوية في قاعدة البيانات بأحرف صغيرة. والبحث لا يفرّق بين حالة الأحرف. وعند العرض يُحوَّل النص إلى الصيغة القياسية (أرقام التسجيل بأحرف كبيرة، والأسماء بنمط Title Case).

الحقول المستثناة — وتُخزَّن كما وردت تمامًا:

الحقل	السبب
etsi_identifier	صيغته محدَّدة بمعيار
الاسم المميَّز (DN) للشهادة	داخل في التوقيع التشفيري ولا يجوز تغييره
حقول *_latin	نقل حرفي لاتيني — يحتفظ بصورته الأصلية
document_number	رقم مستند رسمي
قيم التجزئة	كل بِت فيها ذو دلالة

من أين جاءت هذه القاعدة

كان المواطن يسجّل باسم АБ12345678 ثم يحاول الدخول بـ аб12345678، فيراه النظام شخصًا آخر، فينشأ حساب مكرَّر. وتوحيد حالة الأحرف على مستوى التخزين يُزيل هذا الصنف من الأخطاء برمّته.

تدرج الصلاحيات

superadmin (1) → admin (2) → manager (3) → user (4)

قواعد صارمة:

الدور	يستطيع	لا يستطيع
superadmin	إضافة حسابات المشرفين وحذفها	—
admin	منح صلاحيات manager	إدارة حسابات المشرفين
manager	العمليات اليومية	إضافة أشخاص
user	أفعاله هو	منح الصلاحيات

المشرف الأعلى حساب منفصل محميّ بمصادقة متعدّدة العوامل. ويُنشأ عبر معالج تهيئة: قائمة سماح للدعوات ← Google ← eID ← رمز OTP بالبريد ← TOTP + رموز استرداد. ويُخزَّن في جدول خاص مُفهرَس بهوية Google.

والنتيجة العملية: يمكن للشخص الواحد أن يكون مشرف eID ومشرفًا أعلى عبر Google في آن واحد — حسابان منفصلان ومسارا دخول منفصلان. وكل عمليات دخول المشرف الأعلى محميّة بمصادقة متعدّدة العوامل.

وتُمنح صلاحيات المشرف برقم التسجيل، في مقابل مستخدم مسجَّل في eID المحلي.

منح الصلاحيات بتوقيع

القاعدة: عند منح شخصٍ صلاحية manager في جهةٍ ما يُرسَل إليه إشعار توقيع eID SIGN، ولا تصير الصلاحية ACTIVE إلّا بعد موافقته بـPIN2.

والسبب: منح الصلاحيات فعلٌ ذو أثر قانوني. فإن عيّن المشرف شخصًا مسؤولًا من طرف واحد، جاز لذلك الشخص إنكارُه لاحقًا. أمّا التوقيع بـ PIN2 فيوفّر عدم الإنكار، ويسدّ باب القول «أنا لم أوافق».

قواعد الاستدعاء الراجع (callback)

القاعدة: لا يُعاد الاستدعاء الراجع إلّا في مسارات الجهاز نفسه (same-device). وفي ما عدا ذلك يُستَقصى وضع الجلسة (poll).

الحالة	الآلية
المستخدم على جهاز واحد (رابط عميق)	استدعاء راجع
رمز QR — جهاز ثانٍ	استقصاء الجلسة (long-poll)
إشعار دفع	استقصاء الجلسة

والسبب: في مسارٍ بدأ على جهاز آخر، لا يعرف الاستدعاء الراجع إلى أين يعود. أمّا الاستقصاء فيجعل المتصفّح الذي بدأ المسار مصدرَ الحقيقة، ويُبقي المسار واضحًا لا لبس فيه.

الروابط العميقة لأطراف ثالثة — تُمرَّر في معامل الاستدعاء الراجع، وعند الانتهاء يُستدعى التطبيق المعني إلى الواجهة.

الربط مع Google

القاعدة: قبل ربط حساب Google يجب التحقّق من المستخدم بـ eID. فالربط الأول يقيّد الحساب بشخص حقيقي؛ وبعدها يجوز الدخول مباشرةً عبر Google. والفكّ ممكن أيضًا.

والسبب: حساب Google يستطيع أيّ أحد إنشاءه، ولا يصحّ قبوله وحده تعريفًا لهوية المواطن. فإذا رُبط مرّةً عبر eID صار ذلك الحساب يشير إلى مواطن بعينه.

RP ↔ rp_app

القاعدة: لا يُسجَّل لدى eID سوى الجهة المعتمِدة. أمّا التطبيقات والأنظمة الفرعية المتعدّدة تحت جهةٍ واحدة فتُمرَّر عبر الحقلين rp_app وrp_app_url.

وبذلك تُظهر السجلّات وشاشة المستخدم أي تطبيق أرسل الطلب — من دون تسجيل جهة معتمِدة لكل تطبيق ومن دون تشتيت بيانات الاعتماد.

الخروج ينتهي عند النطاق الذي بدأ منه

القاعدة: عند تسجيل الخروج يعود المستخدم إلى النطاق الذي بدأ منه، ولا يُقذف إلى /login في الدخول الموحّد.

والسبب: كان المستخدم داخل تطبيق الجهة المعتمِدة. والوصول بعد الخروج إلى شاشة دخولٍ لنطاقٍ غريب تمامًا يُربكه. فينبغي أن ينتهي الخروج داخل التطبيق الذي بدأ فيه.

لبيانات الاعتماد مصدر واحد

القاعدة: يُنشأ عميل OAuth وسرّه في الدخول الموحّد فقط، ولا يعيشان إلّا هناك. ولا يُنشئهما أي نظام آخر ولا يخزّنهما ولا يعرضهما.

وDeveloper Portal هو المثال المِعياري على هذه القاعدة: فهو يقدّم الإرشاد لتسجيل التطبيق، لكنّه لا يُنشئ عملاء، بل يكتفي برابط عميق إلى وحدة تحكّم SSO.

الوثائق شيفرة

القاعدة: لكل مستودع مجلّده docs/ وموقعه المبنيّ بـ MkDocs. فالوثائق تعيش في المستودع نفسه مع الشيفرة، وتتغيّر معها في طلب الدمج نفسه.

التغطية اللغوية: المنغولية والإنجليزية حدًّا أدنى؛ وتُضاف الصينية والروسية في المستودعات الرئيسة. راجع التعدّد اللغوي للتفاصيل.

Clean Architecture — بلا استيراد عكسي

القاعدة: handler → usecase → repository → domain. والاعتمادية تسير في اتّجاه واحد فقط. ونواة الأعمال (domain وusecase) لا تستورد إطار عمل ويب أبدًا.

وفحصٌ يسير: إن وُجد في ملفٍّ داخل domain/ استيرادٌ لـ net/http أو chi، فالقاعدة مُنتهَكة.

قائمة تحقّق لإضافة منصّة جديدة

• [ ] المصادقة عبر الدخول الموحّد بوصف المنصّة جهةً معتمِدة لـ OIDC — ولا نظام كلمات مرور خاص بها
• [ ] تدرّج الصلاحيات superadmin → admin → manager → user
• [ ] نصوص الهوية بأحرف صغيرة في قاعدة البيانات، والحقول المستثناة محدَّدة
• [ ] تفعيل RLS في Postgres + حارس التحقّق عند الإقلاع
• [ ] سجل تدقيق — مترابط بسلسلة تجزئة
• [ ] ضبط الترويسات الأمنية وقائمة سماح CORS وتحديد المعدّل
• [ ] إغلاق /metrics و/swagger في الإنتاج
• [ ] مجلّد docs/ وموقع MkDocs، بالمنغولية والإنجليزية
• [ ] التكامل المستمر: بناء + اختبارات + فحص صارم للوثائق