إنتقل إلى المحتوى الرئيسي

دورة حياة التحدي

تمر كل مصادقة بآلة حالات قصيرة واحدة. ويساعد فهمها على تشخيص التصرف غير المتوقع للتحدي.

الحالات​

الحالات النهائية الثلاث — approved وdenied وexpired — ثابتة. فبمجرد وصول التحدي إلى إحداها، تعيد الاستعلامات اللاحقة القيمة نفسها حتى تحذفه عملية التنظيف الدورية في النهاية.

التوقيتات​

المعلمةالقيمةالملاحظات
مدة صلاحية التحدي5 دقائقالفترة بين الإنشاء وexpired
عمر JWT5 دقائقالفترة بين الإصدار وexp
تخزين JWKS مؤقتًا في SDK5 دقائقالفترة بين عمليتي جلب
تفاوت الساعة (HMAC وJWT)±5 دقائق (HMAC) / ±30 ثانية (JWT)من جهة التطبيق المعتمد على المصادقة RP

مدة التحدي البالغة خمس دقائق هي سبب ضبط المهلة الافتراضية لـpoll_challenge إلى 4 دقائق و30 ثانية؛ فيعيد العميل ChallengeTimeoutError قبل أن يعيد الخادم الحالة expired، مما يجعل تدفق التحكم أوضح.

تدوير الأسرار ليس مشكلة​

لا يؤدي تغيير سر HMAC للتطبيق إلى إبطال التحديات الجارية. يرتبط التحدي بمعرّفه والأصل والمستخدم، ولا يعتمد على سر RP. قد تشاهد مجموعة خوادم RP أخطاء INVALID_SIGNATURE لفترة وجيزة أثناء نشر السر الجديد، لكن التحديات القائمة تحتفظ بحالاتها.

تكرار الطلبات والسلامة​

  • إنشاء التحدي ليس عملية قابلة للتكرار بلا أثر إضافي (idempotent). استدعاءان متتاليان يرسلان إشعارين للهاتف. امنع النقرات المكررة لدى RP إذا ضغط المستخدم زر الدخول مرتين.
  • الاستعلام عن الحالة قابل للتكرار ومنخفض التكلفة؛ فهو عملية بحث مفهرسة واحدة في مخزن التحديات داخل الذاكرة، لا قراءة لقاعدة البيانات.
  • الموافقة تحدث مرة واحدة. لا يستطيع المستخدم الموافقة على التحدي نفسه مرتين؛ فتحوّله اللمسة الأولى إلى approved ويتجاهل الخادم اللمسات التالية.

حالات الإخفاق ومعانيها​

العَرَضالسبب
404 في create_challengeالمستخدم غير مسجل ضمن مستأجر هذا التطبيق
403 UNREGISTERED_ORIGIN في create_challengeلم يُسجّل الأصل مسبقًا عبر POST إلى /v1/origins
بقاء الحالة pending حتى expiredلم يصل الإشعار إلى الهاتف (الإنترنت؟ وضع عدم الإزعاج؟)
INVALID_SIGNATURE عند create_challenge فقطاختلاف السر بين تطبيقك وZTXBAS؛ دوّره وأعد النشر
TIMESTAMP_EXPIRED في كل استدعاءساعة مضيف RP غير صحيحة؛ فعّل NTP

موضوعات ذات صلة​