نحن نستخدم DiscourseSSO، وتواجه المستخدمين بشكل متقطع مشاكل في تسجيل الدخول (مشابهة لـ Sporadic issue wp-discourse/SSO: Nonce has already expired). كنت أحاول تصحيح هذا عن طريق إضافة بعض التسجيلات الإضافية، ولحسن الحظ واجهت المشكلة بعد يومين. للتوضيح، تسجيل الدخول يعمل في معظم الأوقات، فقط بشكل متقطع (قد يكون لمدة 5 دقائق في اليوم) يواجه المستخدمون مشاكل في تسجيل الدخول.
نحن نستخدم إعداد المجلدات الفرعية على مجموعة متعددة العقد، باستخدام قاعدة بيانات مشتركة خارجية و Redis إذا كان ذلك يحدث فرقًا. هناك سيناريوهان فاشلان:
انتهاء صلاحية Nonce
عند إعادة توجيه المستخدم إلى /session/sso_login، لا يحصل SessionController على session_id في الجلسة وبالتالي لا يتمكن من البحث عن Nonce. حاولت تسجيل الجلسة (Rails.logger.warn(\"Verbose SSO log: Session #{session.keys.map {|key| [key, session[key]].join('=')}.join(',')}\")) وطبعت جلسة فارغة. لقد تحققت من أن المتصفح يرسل ملف تعريف الارتباط “_forum_session” كما تم استلامه في الطلب السابق، ويتم تسجيل ملف تعريف الارتباط على الخادم إذا تم تسجيل الدخول في SessionController (Rails.logger.warn(\"Verbose SSO log: Cookies #{cookies.map {|cookie| cookie.join('=')}.join(',')}\")).
يكتمل تسجيل الدخول ولكن المستخدم يرى خطأ تسجيل الدخول على الشاشة
عند إعادة توجيه المستخدم إلى /session/sso_login، يكون SessionController قادرًا على التحقق من بيانات SSO وتسجيل دخول المستخدم (أرى Verbose SSO log: User was logged on user5 في السجلات). ولكن عند إعادة توجيهه إلى /forums/latest، يرى المستخدم خطأ على الشاشة. لاحظت أنه في التدفق العامل، يقوم هذا الإجراء بمسح/إرجاع ملف تعريف الارتباط “cn” فارغًا، ولكن في السيناريو الفاشل، يقوم فقط بتحديث وإرجاع ملف تعريف الارتباط “_t”. تخميني هو أن هذا السيناريو قد يكون مرتبطًا أيضًا ببيانات الجلسة المفقودة.
إذا انتظرنا 5 دقائق تقريبًا وحاولنا مرة أخرى، فكل شيء يبدأ في العمل بشكل جيد مرة أخرى.
لم أختبر ما إذا كان جميع المستخدمين الذين يصلون إلى الموقع في ذلك الوقت يواجهون المشكلة أم لا، ولكن قيل لي بشكل غير رسمي أن العديد من المستخدمين واجهوها مرة واحدة على مثيلنا.
ماذا تستخدم لإعداد المجلدات الفرعية؟ إذا كان لديك نوع من جدار حماية تطبيقات الويب أمام Discourse، فقد يكون من المفيد التحقق من مشاكل التخزين المؤقت. من واقع خبرتنا، هذا هو أول شيء يجب استبعاده.
شكراً لردك ليوناردو. نحن نستخدم nginx كبوابة رئيسية لدينا والتي ترسل عناوين URL المستندة إلى المسار إلى nginx داخل حاوية Discourse.
لقد أضفت هذين السطرين في بداية session_controller.rb/sso و session_controller.rb/sso_login
if SiteSetting.verbose_discourse_connect_logging
Rails.logger.warn("Verbose SSO log: Cookies #{cookies.map {|cookie| cookie.join('=')}.join(',')}")
Rails.logger.warn("Verbose SSO log: Session #{session.keys.map {|key| [key, session[key]].join('=')}.join(',')}")
end
بالنسبة لسيناريو الفشل الأول المذكور أعلاه، حصلت على ما يلي لـ /sso (على العقدة 1 من الكتلة متعددة العقد)
Verbose SSO log: Cookies cn=12,_forum_session=ZjBveGorRVN1bU0zeGRKVHZtWUZDamUxTUJSUkJHUDZDaHhLMkh3U0lXMlpCYS9PTnpJWEovcTlZVDFTSTJuNkVNUE9NdlNvVWlidStIdk9SeTlRYzZ5YVp0N0pXdmhnTldlaSt4d1o3TC9mUm1nSUhsOUtiWFRyVGZBYkJLRHRRR0lFZmM0RkVxLzl0V2JEODR4NGMxQUJvOGhpdVc0c2JsdDFESHo2TWxJPS0tRXZTL0FHZlM1Yy9QVWJkc2xaaTYvUT09--36fa626c698a401db1e7f13276ee6bfde16dea77,sessid=6b4afa7755dc9aa54e3fb16453a28324,<ADDITIONAL_COOKIES_REDACTED>
Verbose SSO log: Session
Verbose SSO log: Setting nonce 8199453c67e347124ecb2e57e5738336 with key SSO_NONCE_8199453c67e347124ecb2e57e5738336
والتالي لـ /sso_login (على العقدة 2 من الكتلة متعددة العقد)
Verbose SSO log: Cookies cn=12,_forum_session=WFRkNThYYUZwUnlOQjF5VHdUZGRUWE1UNUx2a3Z5ZlJCOGl0VFRRUlF2bm5vQUQzMWdaUVZVUnJkNmdIUjlRTE52d1B5MXJnV0svWkJMRWZrOU5XellvV0IzMTBScERwM0lzT3VIUWc2SEppb2xpTlkxaFpuc1dvU2d4SkdZRXFYYjJzakRQTXFmS2lYTlhxVEd5Zi9nQ3dZQnVUR1pDSndScGZhcVNJOW1ZPS0tNFduSE1YRDk5cWdMRXNsWnBzbDVhZz09--00ab1b89ff4cf05c9f3f3ed71eec9c0c4557f032,sessid=6b4afa7755dc9aa54e3fb16453a28324,<ADDITIONAL_COOKIES_REDACTED>
Verbose SSO log: Session
Verbose SSO log: Checking nonce 8199453c67e347124ecb2e57e5738336 with key SSO_NONCE_8199453c67e347124ecb2e57e5738336
Verbose SSO log: Nonce is incorrect, was generated in a different browser session, or has expired
هل يتعطل تسجيل الدخول لجميع المستخدمين في نفس الوقت؟ أم أنه يحدث في أوقات مختلفة لكل مستخدم؟
حقيقة أنه يبدأ في العمل مرة أخرى بعد فترة من الوقت تجعلني أتساءل عما إذا كانت هناك ذاكرة تخزين مؤقت متضمنة. هل يقوم تكوين NGINX الخاص بك، أو أي وكيل وسيط آخر (مثل cloudflare)، بإجراء أي تخزين مؤقت؟
It breaks for all users for that short duration. My first guess was an intermediate node messing with the data, but when I logged cookies from the controller (as explained above) I was able to see the cookies. Is there anything else that I should check as well ?
يكسر لجميع المستخدمين لتلك المدة القصيرة. كان تخميني الأول هو أن عقدة وسيطة تعبث بالبيانات، ولكن عندما قمت بتسجيل ملفات تعريف الارتباط من وحدة التحكم (كما هو موضح أعلاه) تمكنت من رؤية ملفات تعريف الارتباط. هل هناك أي شيء آخر يجب أن أتحقق منه أيضًا؟