أخطاء OAuth عرضية

نحن نستخدم OAuth خارجي للمصادقة على المستخدمين. في بعض الأحيان، يتلقى المستخدمون الخطأ 500 عند القدوم إلى المنصة: مقتطف من سجل الأخطاء:

بدأ GET "/auth/oauth2_basic/callback?code=[coderemoved]&state=[stateremoved]" من [IP] في [timestamp]
(oauth2_basic) تم اكتشاف نقطة نهاية الإعداد، ويتم تشغيلها الآن.
(oauth2_basic) بدأت مرحلة رد الاتصال.
Faraday::TimeoutError (Timeout::Error)
lib/final_destination/resolver.rb:31:in `block in lookup'
lib/final_destination/resolver.rb:8:in `synchronize'
lib/final_destination/resolver.rb:8:in `lookup'
lib/final_destination/ssrf_detector.rb:127:in `lookup_ips'
lib/final_destination/ssrf_detector.rb:95:in `lookup_and_filter_ips'
lib/final_destination/http.rb:13:in `connect'
lib/middleware/omniauth_bypass_middleware.rb:43:in `call'
lib/middleware/content_security_policy.rb:12:in `call'
lib/middleware/anonymous_cache.rb:387:in `call'
lib/middleware/gtm_script_nonce_injector.rb:10:in `call'
config/initializers/100-quiet_logger.rb:20:in `call'
config/initializers/100-silence_logger.rb:29:in `call'
lib/middleware/enforce_hostname.rb:24:in `call'
lib/middleware/request_tracker.rb:233:in `call'

إذا قام المستخدم فقط بتحديث الصفحة، فإن كل شيء يعمل، مع معلومات السجل:

بدأ GET "/auth/oauth2_basic/callback?code=[coderemoved]&state=[stateremoved]" من [IP] في [timestamp]
(oauth2_basic) تم اكتشاف نقطة نهاية الإعداد، ويتم تشغيلها الآن.
(oauth2_basic) بدأت مرحلة رد الاتصال.
Processing by Users::OmniauthCallbacksController#complete as HTML
  Parameters: {"code"=>"[coderemoved]", "state"=>"[stateremoved]", "provider"=>"oauth2_basic"}
Deprecation notice: `SiteSetting.anonymous_posting_min_trust_level` has been deprecated. Please use `SiteSetting.anonymous_posting_allowed_groups` instead. (removal in Discourse 3.3) 
At /var/www/discourse/lib/site_setting_extension.rb:160:in `public_send`
start
Redirected to https://[pageremoved]
Completed 302 Found in 83ms (ActiveRecord: 0.0ms | Allocations: 11138)

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

رفع هذا. أنا أواجه نفس المشاكل بالضبط.

يشير خطأ المهلة إلى مشكلة في الشبكة. قد تكون مجرد خلل في الشبكة.

كنت أفكر في ذلك، لكن الخطأ يظهر بسرعة كبيرة لدرجة أنه لا يمكن أن يكون سلوكًا طبيعيًا. أتساءل عما إذا كان هناك مهلة مفرطة في البحث عن نظام أسماء النطاقات (DNS) في مكان ما:

  1. الخطأ في “resolver.rb”
  2. يتم إصلاحه مؤقتًا عن طريق التحديث - عندما يتم تخزين بحث نظام أسماء النطاقات (DNS) مؤقتًا
  3. لسبب غير مفهوم تمامًا، لا يمكنني جعله يقرأ مستند اكتشاف OIDC من أي عنوان URL يتضمن نظام أسماء النطاقات (DNS) المستضاف ذاتيًا. هذا على الرغم من حقيقة أنني قادر تمامًا على استخدام curl للملف يدويًا من داخل مثيل docker. لقد استبعدت العديد من المتغيرات المختلفة ويبدو أن نظام أسماء النطاقات (DNS) هو العامل المشترك الوحيد.

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

21/Jan/2024:23:10:21 +0000] "POST /application/o/token/ HTTP/1.1" 200 7998 "-" "Faraday v2.9.0"

عندما يفشل، وطلبان:

[21/Jan/2024:23:21:03 +0000] "POST /application/o/token/ HTTP/1.1" 200 7998 "-" "Faraday v2.9.0"
[21/Jan/2024:23:21:05 +0000] "GET /application/o/userinfo/ HTTP/1.1" 200 5254 "-" "Faraday v2.9.0"

عندما ينجح. بغض النظر، لا يستغرق الأمر أكثر من 5 ثوانٍ. لم أحاول بعد إعداد وكيل لخادم OIDC يستخدم نظام أسماء النطاقات (DNS) الخاص بـ Cloudflare، ولكن هذه ستكون خطوتي التالية.

الحكمة الشائعة هي أن الأمر دائمًا يتعلق بنظام أسماء النطاقات (DNS).

حسنًا، إنها بالتأكيد مشكلة في نظام أسماء النطاقات (DNS). بدلاً من إعداد وكيل، أضفت خادم OIDC الخاص بي إلى ملف hosts في حاوية Docker ويبدو أنه يعمل الآن. ومع ذلك، هذا حل هش وغير مثالي؛ أعتقد أن المطورين بحاجة إلى إصلاح المهلة الزمنية لجعلها شيئًا معقولًا. هذه الحالة تذكرني بقصة البريد الإلكتروني لمسافة 500 ميل.

يمكنك إضافة أشياء إلى ملف app.yml الخاص بك لتحديث /etc/hosts عند إعادة البناء. يمكنك الاطلاع على بعض القوالب الأخرى للحصول على أمثلة.

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

لا أعرف أين يمكنني تغيير مهلة الانتهاء. لا أتذكر أنني فعلت ذلك من قبل.

في حالتي، تجلس آلات IdP و Discourse بجوار بعضهما البعض، وفي حين لا يمكن لأحد استبعاد مشاكل الشبكة المحتملة تمامًا، لا تواجه أي خدمة أخرى هذه المشكلة.