بعد إعادة بناء اليوم باستخدام الإصدار 3.3.3 (أحدث إصدار مستقر تم إصداره قبل أيام قليلة)، توقف تسجيل الدخول الموحد (SSO) عن العمل. لا يزال المستخدمون المسجلون دخولهم يعملون بشكل جيد في الوقت الحالي، ولكن الجلسات الجديدة تنهي تدفق تسجيل الدخول الموحد (SSO) بالخطأ:
انتهت مهلة تسجيل دخول الحساب، يرجى محاولة تسجيل الدخول مرة أخرى.
تمكين تسجيل الدخول الموحد المفصل (verbose discourse connect logging) يُظهر:
سجل تسجيل الدخول الموحد المفصل: الرقم غير صحيح، تم إنشاؤه في جلسة متصفح مختلفة، أو انتهت صلاحيته.
ومع ذلك، لم يتغير أي شيء في تدفق تسجيل الدخول الموحد (SSO) لدينا في السنوات الأخيرة. الساعات بين الخوادم متزامنة.
من ناحية أخرى، قمنا مؤخرًا بتحديث الإصدار إلى 3.3.3 (من 3.3.2) والذي يحتوي على إصلاحات أمنية تتعلق بـ Discourse Connect والتي قد تكون ذات صلة.
من غير المرجح أن يكون ذا صلة، ولكن إعادة البناء كانت لـ تمكين شبكة توصيل المحتوى (CDN). ولكن، لقد قمت بالفعل بالتراجع عن كل تلك التغييرات ولا تزال مشكلة تسجيل الدخول الموحد (SSO) قائمة.
بعد عدة عمليات إعادة بناء، تمكنت من إعادة تفعيل SSO عن طريق تثبيته مرة أخرى على الإصدار v3.3.2، لذلك يبدو أن شيئًا ما قد تم تقديمه في الإصدار v3.3.3 أدى إلى تعطيل دعم SSO.
ألقيت نظرة سريعة على git diff v3.3.2 v3.3.3 ولم يبرز شيء واضح، ولكنه يحتوي على تغييرات تتعلق بـ Discourse Connect.
ومع ذلك، أشك في أن هذا سيبدأ في التأثير على المزيد من الأشخاص مع انتقالهم إلى الإصدار 3.3.3 وبدء انتهاء صلاحية جلسات المستخدمين وفشلها في التجديد. ربما يستحق الأمر نظرة فاحصة من قبل شخص يعرف الكود، خاصة تدفق SSO؟ /cc @sam
ملاحظة: لست متأكدًا مما إذا كان ذلك قد يكون ذا صلة: لقد قمت بالتحديث إلى الإصدار 3.3.3 قبل أكثر من يوم، ولكن المشكلات بدت تظهر فقط بعد فترة وجيزة من إعادة البناء عبر وحدة التحكم قبل بضع ساعات (لتمكين شبكة توصيل المحتوى CDN، ولكن التراجع عن ذلك لم يحل مشكلة SSO).
نعم، بمعنى أن معظم الناس يقومون بتشغيل الفرع الذي اجتاز الاختبارات، ولكن لا بمعنى أنه أحدث إصدار على الفرع المستقر، تم شحنه هذا الأسبوع: 3.3.3: Security and maintenance release
إنها فرصة ضئيلة، ولكن هل تقوم بإنشاء الـ Nonce في جلسة متصفح مختلفة، على سبيل المثال عن طريق إجراء طلبات الـ SSO من الواجهة الخلفية لتطبيقك، بدلاً من جعل المستخدمين يمرون بعملية الـ SSO باستخدام عمليات إعادة توجيه المتصفح؟
هناك إعداد موقع مخفي يسمى discourse_connect_csrf_protection وهو ممكّن افتراضيًا. للسماح بإجراء طلبات الـ SSO من خارج جلسة المستخدم، يجب تعطيله.
أفترض أن هذا الإعداد كان موجودًا في الإصدار 3.3.2، ولكن ربما تمت إضافته لاحقًا.
بينما لا نقوم بأي أشياء غير عادية في SSO، لقد جربت ذلك على أي حال عن طريق تعطيله في وحدة تحكم Rails وكل ما فعلته هو إزالة رسالة الخطأ، بمعنى أنه عندما أعاد موفر SSO التوجيه إلى Discourse، بدلاً من خطأ انتهت صلاحية تسجيل دخول الحساب، يرجى محاولة تسجيل الدخول مرة أخرى.، لم تكن هناك رسالة على الإطلاق (خطأ أو غير ذلك) - ولكن، للأسف، لا يزال مسجل الخروج.
أنا أيضًا أتمسك بالقش هنا لأن هذا غريب جدًا. أعتقد أن حقيقة أن المشكلة لم تظهر عندما قمنا بالتحديث الأولي إلى 3.3.3 عبر واجهة الويب ولكن فقط (بعد حوالي 36 ساعة) لاحقًا بعد إعادة بناء وحدة التحكم قد تكون دليلًا، لكنني لا أعرف ما يكفي عن الاختلافات بين الاثنين.
لقد حاولت الترقية مرة أخرى إلى 3.3.3 وعادت المشكلة على الفور. التبديل مرة أخرى إلى 3.3.2 جعل SSO يعمل مرة أخرى.
أعتقد أن المشكلة هنا ليست في إصلاح أمان DiscourseConnect بل في تغيير nginx. في tests-passed، اضطررنا إلى إجراء متابعة يوم الخميس لأنها كانت تسبب مشاكل في بعض البيئات، وأشار مستخدم آخر على Github إلى مشاكل CSRF.
يسعدني أن أبلغكم أن هذا نجح!
أقدر لك تخصيص وقت للنظر في هذا الأمر، خاصة في عطلة نهاية الأسبوع وبالنظر إلى أن كلاً من stable و SSO هما مجالان متخصصان، ولكن نأمل أن يساعد ذلك الآخرين أيضًا. شكرًا لك!
سأراقب دمج طلب السحب (PR).
