الانتقال إلى المحتوى الرئيسي
المصادقة ميزة جديدة. شغّل كل عملية استيراد في تطبيق ضمن البيئة التجريبية أولاً، ثم استورد إلى تطبيقك في بيئة الإنتاج.
ينقل الاستيراد الأشخاص من منصة هوية أخرى إلى Didit Authentication. تنتقل معهم كلمة المرور، والبريد الإلكتروني المُتحقَّق منه، وروابط تسجيل الدخول الاجتماعي، وتطبيق المصادقة، وأدوار المؤسسة. لا يتغير شيء بالنسبة لهم حتى يسجّل تطبيقك دخولهم عبر Didit. تستخدم عمليات الاستيراد واجهة برمجة تطبيقات إدارة المصادقة الخاصة بتطبيقك، مع جلسة في وحدة التحكم تتضمن write:authentication (أو read:authentication لعرض القوائم). لا تستخدم هذه العمليات token المستخدم النهائي ولا مفتاح API للتحقق. في الأمثلة، يكون MANAGEMENT_BASE كما يلي:

​
طريقتان للاستيراد

​
استيراد ملف

​
1. الرفع

يكون كل مفتاح keep_* بالقيمة true ما لم ترسل false. تعيد الواجهة الاستجابة 202 مع مهمة. يحتفظ التطبيق بـ5 ملفات مرفوعة كحد أقصى في آنٍ واحد.

​
2. مراجعة التشغيل التجريبي

يبدأ كل رفع بتشغيل تجريبي. يتحقق هذا التشغيل من كل شخص ولا يكتب أي شيء. استعلم عن GET import-jobs/{id}/ بشكل دوري: يعرض التشغيل التجريبي الفاشل أخطاءه. صحّح الملف وارفعه مجدداً.

​
3. بدء الاستيراد

يستورد POST import-jobs/{id}/start/ ما تحقق منه التشغيل التجريبي، ويعيد 202.
  • يُستورد الأشخاص على دفعات من 1,000. تُعتمد كل دفعة بشكل مستقل.
  • يعمل استيراد واحد فقط لكل تطبيق في المرة الواحدة (وإلا فستظهر رسالة import_running).
  • يُستأنف الاستيراد الذي انقطع بعد آخر دفعة تم اعتمادها.
  • يُتخطّى الأشخاص الذين استُوردوا سابقاً، لذا يمكنك تشغيل الملف نفسه مرة أخرى.
  • يتلقى الشخص الذي بدأ الاستيراد بريداً إلكترونياً عند انتهائه أو توقفه.
يُخزَّن الملف المرفوع مشفّراً. يُحذف عند انتهاء الاستيراد، أو عند فشل تشغيله التجريبي، أو بعد 24 ساعة من تشغيل تجريبي لم يُستورد بعده.

​
استيراد على دفعات

أرسل حتى 1,000 شخص في كل طلب، مع idempotency_key بطول 100 حرف كحد أقصى.
  • يعيد التشغيل التجريبي 200 مع النتيجة، ولا يكتب أي شيء.
  • مع dry_run: false، يعيد الاستيراد الناجح 201. تعيد الدفعة التي تحتوي على أي خطأ 400 ولا تستورد أحداً.
  • إعادة إرسال طلب معتمد بالمفتاح نفسه تعيد نتيجته المسجلة. أما المفتاح نفسه مع محتوى مختلف فيعيد 400 {"idempotency_key": "different_payload"}.
  • تُرسل معاملات Firebase داخل كائن firebase: {signer_key, salt_separator, rounds, mem_cost}.
  • يعرض GET imports/ الدفعات المعتمدة.

​
تنسيق الملف

​
JSON

مصفوفة من الأشخاص، أو كائن يحتوي حقل users بهذه المصفوفة.

​
CSV

الأعمدة نفسها ذات القيمة المفردة، بالإضافة إلى google_id وapple_id وgithub_id وmicrosoft_id وmicrosoft_tenant_id وorganization_slug وorganization_name وorganization_role. يأخذ الشخص الذي ينتمي إلى عدة مؤسسات سطراً واحداً لكل مؤسسة.
تُعد الحقول أو الأعمدة غير المعروفة أخطاءً، ولا تُتجاهل أبداً.

​
التكرارات والحسابات الموجودة

  • تُدمج الأسطر ذات البريد الإلكتروني نفسه في شخص واحد. يُحسب السطر المطابق تماماً مكرراً. يُدمج السطر الذي يحتوي روابط أو مؤسسات أو تطبيق مصادقة أكثر.
  • يُعد وجود تجزئتين مختلفتين لكلمة المرور، أو سرين مختلفين لتطبيق المصادقة، أو دورين مختلفين في المؤسسة لشخص واحد، خطأً. وكذلك الأمر إذا ادّعى شخصان الحقل external_id نفسه، أو معرّف الحساب نفسه لدى المزوّد.
  • إذا كان هناك حساب بالبريد الإلكتروني نفسه وأنشأه استيراد سابق، يُتخطّى الشخص (already_imported). وإذا سجّل الشخص بنفسه، يُعد ذلك خطأ identity_conflict. لا يُغيّر الاستيراد أبداً حساباً موجوداً.

​
كلمات المرور

تُخزَّن معاملات Firebase مشفّرةً ولهذا التطبيق وحده. أي صيغة أخرى، أو تكلفة تتجاوز هذه الحدود، تعني أن الشخص يحتاج إلى كلمة مرور جديدة. بعد أول تسجيل دخول ناجح للشخص، تعيد Didit تخزين كلمة مروره بصيغتها الخاصة.

​
الأشخاص بدون كلمة مرور صالحة للاستخدام

عندما لا يكون لدى الشخص تجزئة، أو تكون التجزئة غير مدعومة، تتلقى محاولة تسجيل الدخول بكلمة المرور الرد المعتاد الخاص بكلمة المرور الخاطئة. ترسل Didit إليه أيضاً بريداً إلكترونياً يحتوي على رابط لتعيين كلمة مرور جديدة (صالح لمدة 30 دقيقة، ومرة واحدة في اليوم على الأكثر). يحدث هذا فقط عندما تم التحقق من بريده الإلكتروني، ولم يُحظر الحساب، وكان تسجيل الدخول بكلمة المرور مفعّلاً. في النتيجة، يُحصي reset_required الأشخاص الذين لا يملكون كلمة مرور صالحة للاستخدام. ويُحصي reset_emails من بينهم أصحاب البريد الإلكتروني المتحقَّق منه فقط، فهم وحدهم من يمكن الوصول إليهم بهذه الطريقة. لا يستطيع الأشخاص الذين لم يتحقق من بريدهم الإلكتروني تسجيل الدخول بكلمة مرور. ومع ذلك يمكنهم تسجيل الدخول برمز يُرسل إلى بريدهم الإلكتروني إذا فعّلت هذه الطريقة.

​
الروابط الاجتماعية وتطبيقات المصادقة والمؤسسات

  • الروابط الاجتماعية تُحتفظ بها للمزوّدين الذين سبق أن هيّأهم تطبيقك، ضمن معرّف العميل الحالي. عندها لا يحتاج تسجيل الدخول العائد إلى إثبات بالبريد الإلكتروني. معرّفات Google وGitHub عامة على مستوى العالم. أما معرّفات Apple فهي خاصة بفريق المطوّر، ومعرّفات Microsoft خاصة بتسجيل التطبيق، لذلك لا تتطابق هذه الروابط إلا إذا كانت منصتك القديمة تستخدم الفريق أو التسجيل نفسه. الروابط المرتبطة بمزوّدين لم تُهيَّئ لديك تُحسب ضمن social_unavailable ولا تُستورد.
  • تطبيقات المصادقة (أسرار TOTP: SHA-1، و6 أرقام، و30 ثانية) تُخزَّن مشفّرة. يجب على الأشخاص المستوردين استخدامها كعامل ثانٍ للتحقق. ولا يحصلون على رموز استرداد.
  • المؤسسات التي لا وجود لها بعد تُنشأ من معرّفها المختصر.
  • مفاتيح المرور لا يمكن استيرادها. فهي تنتمي إلى نطاق تسجيل الدخول القديم لديك، لذلك يضيف الأشخاص مفتاح مرور جديداً بعد أن يسجلوا الدخول عبر Didit.

​
النتائج

تُعيد كل عملية تشغيل تجريبي ودفعة ومهمة النتيجة result نفسها: لا تتضمن الاستجابات أبداً تجزئات كلمات المرور ولا الأملاح ولا أسرار تطبيقات المصادقة ولا قيم الحقول.

​
قبل التبديل

اختبر في تطبيقك في البيئة التجريبية:
  • تسجيل الدخول بكل صيغة كلمة مرور تستوردها،
  • بريد تعيين كلمة مرور جديدة لشخص ليست لديه تجزئة صالحة للاستخدام،
  • تسجيل الدخول الاجتماعي ورموز تطبيقات المصادقة للأشخاص المستوردين،
  • تشغيل الملف نفسه مرتين.
ثم تحقّق من أن vendor_data لكل شخص يطابق القيمة التي تستخدمها لـعمليات التحقق والمعاملات.
آخر تعديل في ٧ نوفمبر ٢٠٢٦