الاحتفاظ بالجلسة على الخادم
استخدم التدفق المستضاف الموضح في دليل البدء السريع لـ JavaScript، مع التعديلات التالية لتطبيق يُعرض من جانب الخادم. أسماء المسارات في الجدول أسماء مسارات في تطبيقك أنت تنفذها، وليست endpoints في واجهة Didit البرمجية.
أرسل فقط مرجعاً عشوائياً لجلسة التطبيق في ملف تعريف ارتباط بالخصائص
Secure وHttpOnly وSameSite=Lax مع مسار محدد النطاق. استخدم مدة صلاحية مناسبة، وغيّر المرجع بعد تسجيل الدخول. لا تكشف رمز التحديث الخاص بـ Didit في الخصائص المعروضة أو في مكونات العميل أو في تخزين المتصفح. استخدم Cache-Control: no-store في استجابات الرموز واستجابات الاستدعاء.
لا تعتمد على فحص التخطيط أو الوسيط وحده: تحقّق من الإذن عند كل وصول إلى البيانات وكل عملية تعديل. احمِ عمليات التعديل المصادَقة بملف تعريف الارتباط من هجمات CSRF. اسمح فقط بوجهات ما بعد تسجيل الدخول المُعدّة مسبقاً، ولا تقبل أبداً عنوان URL عشوائياً من معامل returnTo في الاستعلام.
معاينة إصدار الحزمة
تضيف الحزمة المخطط لها الوسيط، وauth() على الخادم، ومسار الاستدعاء، ودعم ملفات تعريف الارتباط من نوع HttpOnly للعرض من جانب الخادم. من المتوقع أن يوفّر المدخل الأساسي /server الدالة verifyToken() مع JWKS مخزّن مؤقتاً. انتظر صادرات الإصدار المتحقَّق منه قبل استخدام هذه الرموز البرمجية. وإلى ذلك الحين، تحقّق من الرموز بنفسك باستخدام أي مكتبة JOSE، كما هو موضح في الرموز وJWKS.
الربط بالمنتجات الأخرى
أنشئ جلسات التحقق وأصدر رموز المراقبة المحددة النطاق على الخادم. استخرجvendor_data من تعيين بيانات الشخص الذي تم التحقق منه. أعد للمتصفح رابط جلسة التحقق أو رمز SDK قصير الأمد فقط. أبقِ DIDIT_API_KEY خارج متغيرات البيئة العامة.
استخدم حزمة SDK للتحقق عبر الويب الموجودة للتحقق، ودليل إرسال المعاملات للمراقبة. ولا يُعد أي منهما مديراً لجلسات المصادقة.
اختبر إعادة تشغيل الاستدعاء، والحالة الخاطئة، والحالة المنتهية الصلاحية، وتزاحم التحديث، والجلسات الملغاة، ورفض CSRF، وتسجيل الخروج قبل الإصدار. راجع الرموز وJWKS للاطلاع على عقد التحقق.