العربية

ما بعد الوفاة
خدمة السحابة
حادث

ما بعد الوفاة: تغيير غير متوقع في `iss` الخاص بـ JWT

تقرير الحادث لتغيير غير متوقع في `iss` الخاص بـ JWT بتاريخ 2024-03-18.

Sijie

Developer

3/25/2024

توقف عن إضاعة أسابيع في مصادقة المستخدم

أطلق تطبيقات آمنة بشكل أسرع مع Logto. قم بدمج مصادقة المستخدم في دقائق وركز على منتجك الأساسي.

ابدأ الآن

الملخص

في تاريخ 2024-03-18، تسبب تحديث في تغيير سلوك مُصدر JWT في Logto Cloud في كسر تدفقات المصادقة للمستخدمين الذين لديهم نطاقات مخصصة و تحقق iss. التصحيح تطلب من هؤلاء المستخدمين تحديث منطق التحقق.

المستخدمون المتأثرون: المستخدمون الذين لديهم نطاقات مخصصة مفعلة ويقومون بالتحقق من iss.
الخطورة: حرجة، تكسر التحقق من iss ضمن تدفقات المصادقة.

السبب الجذري

التحديث قام بتغيير حقل iss ليتطابق مع النطاق المطلوب، مما كسر الأتحققات الموجودة التي كانت تتوقع المُصدر الافتراضي السابق.

الجدول الزمني

2024-03-18 10:00 (UTC): تم نشر التحديثات، مما غير سلوك iss.
2024-03-18 23:30 (UTC): تم استلام أول تقرير من قبل المستخدم عن كسر السلوك الحالي.
2024-03-19 12:00 (UTC): تم تأكيد المشكلة و بدء التحقيق.
2024-03-19 14:00 (UTC): تم تحديد السبب الجذري والتأثير.
2024-03-20 20:00 (UTC): إعداد البريد الإلكتروني للمستخدمين المتأثرين.
2024-03-20 06:00 (UTC): تم إرسال الرسائل الإلكترونية إلى جميع المستخدمين المتأثرين.

تحليل التأثير

تفاصيل الإصدار

يدعم Logto Cloud النطاقات المخصصة للمصادقة، يمكن للمطورين الذين لديهم مستأجرون مفعّلون للنطاقات المخصصة تحديد نقطة النهاية للنطاق المخصص في SDKs، ثم يستخدم المستخدم النهائي هذه النقطة لبدء عملية المصادقة والحصول على الرموز. بعض الرموز تكون في شكل JWT، والتي تتضمن حقل iss يُشير إلى مُصدر هذا الرمز. في السابق، حتى عند استخدام نقطة نهاية النطاق المخصص لطلب رمز الوصول، كان المُصدر يظل وفق النطاق الافتراضي القياسي لدينا ([tenant-id].logto.app).

لكن يجب أن يكون نطاق المُصدر نفس النطاق المطلوب. لذلك أصدرنا تحديثًا لإصلاح هذه المشكلة، والآن سيعكس حقل iss تلقائيًا النطاق المستخدم في الطلب.

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

لقد فشلنا في أخذ التأثير الكامل على التحققات iss الموجودة بعين الاعتبار، ونتيجة لذلك، أصبح هذا الإصدار تغييرًا كبيرًا دون إشعار مسبق.

الحل

أخطرنا المستخدمين المتأثرين عبر البريد الإلكتروني، ناصحين إياهم بتحديث التحقق من iss ليتطابق مع النطاق المطلوب.

ارتداد؟

التغيير هو إصلاح ضروري لحقل المُصدر، وقد يكون بعض المستخدمين قد تكيفوا بالفعل مع السلوك الجديد. التراجع سيُسبب التباسًا وعدم اتساق.

الدروس المستفادة

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

الإجراءات التصحيحية والوقائية

إضافة اختبارات التكامل: إضافة حالات اختبار لتغطية السيناريو في هذا الحادث.
مشاريع مراقبة الميزات: بالإضافة إلى Logto Cloud، أنشئ مشاريع جانبية خاصة بنا وتكامل عميق مع Logto للكشف عن المشاكل المحتملة قبل الإصدارات.

الملخص#

السبب الجذري#

الجدول الزمني#

تحليل التأثير#

تفاصيل الإصدار#

الحل#

ارتداد؟#

الدروس المستفادة#

الإجراءات التصحيحية والوقائية#

الملخص#

السبب الجذري#

الجدول الزمني#

تحليل التأثير#

تفاصيل الإصدار#

الحل#

ارتداد؟#

الدروس المستفادة#

الإجراءات التصحيحية والوقائية#

الملخص

السبب الجذري

الجدول الزمني

تحليل التأثير

تفاصيل الإصدار

الحل

ارتداد؟

الدروس المستفادة

الإجراءات التصحيحية والوقائية

الملخص

السبب الجذري

الجدول الزمني

تحليل التأثير

تفاصيل الإصدار

الحل

ارتداد؟

الدروس المستفادة

الإجراءات التصحيحية والوقائية