أرى هذه الرسالة عند محاولة تفعيل Discourse_id على نظام الاختبار الخاص بي (3.6.0.beta2-latest):
enable_discourse_id: يجب عليك تكوين بيانات اعتماد Discourse ID ('discourse_id_client_id' و 'discourse_id_client_secret') قبل تمكين هذا الإعداد.
أستخدم خادم Oauth محليًا لـ OIDC هنا (keycloak). ربما يتداخل الأسلوبان مع بعضهما البعض؟؟
أعتقد أنه لا يتعارض مع OIDC، ولكن إذا لم يكن مثيلك متاحًا على الإنترنت، فلن تعمل عملية تسجيل الهوية. يوفر موفر هوية Discourse ID آلية تحقق للمثيلات التي تبدأ عملية التسجيل.
النسخة التجريبية متاحة على forum2.netzwissen.de
أرى نفس الرسالة على مثيلين، لا يمتلك أي منهما اتصال OAuth مختلف.
لقد نقلت هذا إلى موضوع منفصل… هل ترى أي أخطاء في /logs على مثيلك؟ يجب أن يعرض بعض التفاصيل الإضافية هناك حول ما لا يعمل تحت الغطاء أثناء عملية التسجيل.
أود أن أفهم الأمر أكثر من الناحية الفنية.
في مثيلاتي، أستخدم مصادقة OIDC مع موفر هوية خارجي (Keycloak 26). يبدو معرف Discourse مشابهًا جدًا؛ إنه مجرد خادم IDP مختلف تستضيفه Discourse.org. ورسائل الخطأ (معرف العميل والسر المفقود) تذكرنا أيضًا بتدفق OAuth الكلاسيكي. هل هذا يعني أنه سيتم تنشيط معرف Discourse كمسار مصادقة IDP إضافي؟ لأنه عندها فقط سيكون مفيدًا لحالتي. ؟؟؟
فقط هذا، ولكن بانتظام نسبيًا بحيث لا علاقة له بالموضوع.
رسالة (تم الإبلاغ عن نسختين)
يستهلك Sidekiq الكثير من الذاكرة (باستخدام: 503.02M) لـ 'rpg-foren-app'، وإعادة التشغيل
تتبع المكدس
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-8.0.2.1/lib/active_support/broadcast_logger.rb:130:in block in warn' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-8.0.2.1/lib/active_support/broadcast_logger.rb:231:in block in dispatch’
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-8.0.2.1/lib/active_support/broadcast_logger.rb:231:in each' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-8.0.2.1/lib/active_support/broadcast_logger.rb:231:in dispatch’
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-8.0.2.1/lib/active_support/broadcast_logger.rb:130:in warn' /var/www/discourse/lib/demon/sidekiq.rb:59:in block in rss_memory_check’
/var/www/discourse/lib/demon/sidekiq.rb:53:in each' /var/www/discourse/lib/demon/sidekiq.rb:53:in rss_memory_check’
config/unicorn.conf.rb:132:in `block (2 levels) in reload
'
نعم، صحيح، Discourse ID هو مُعرّف هوية آخر.
@Tealk خطأ sidekiq غير ذي صلة. هل يمكنك مشاركة تجزئة الالتزام لمثيلك من فضلك؟
بالتأكيد تفضل: 3.5.1 (c96aeda334)
حسناً. إذن سأحتاج إلى معرّف عميل (client ID) على موفّر الهوية الخاص بك (IDP) (للتدفق العام للوصول) أو معرّف عميل (Client ID) و سر العميل (Client Secret) (لتدفق الوصول السري). خيار آخر: إضافة معرّف Discourse كـ وسيط هوية خارجي لموفّر الهوية المحلي. لكلا الخيارين، سأحتاج إلى مزيد من المعلومات 
…
نعم، كل مثيل من Discourse يسجل (في الخلفية) ويقوم بإعداد معرّف عميل وسر عميل.
الآن بعد أن نظرت إلى مثيلك، أرى أخطاء http/https. لكي تعمل الهوية (ID)، يجب أن يكون الموقع تحت https. هذه على الأرجح مشكلتك.
@Tealk تأكد من أن موقعك يعمل بشكل صحيح أيضًا على https.
لا أعرف ما الذي يمكنني تحسينه:
هل تعمل خاصية Discourse ID بالفعل على المنتديات التي تستخدم الفرع المستقر؟ كنت أعتقد أن الميزة لن تضاف إلا بعد الإصدار في أغسطس.
أجل، بالتأكيد، إذا كنت تستخدم قناة stable يا @Tealk، فسيتعين عليك الانتظار حتى الإصدار المستقر التالي ليكون Discourse ID متاحًا لك.
لاحظ أيضًا أن DiscourseConnect هي ميزة منفصلة.
حسنًا، هذا مربك في صفحة “ما الجديد”. هل سيكون من الممكن إضافة الإصدار الذي تم تضمين ميزة منه؟
هذه نقطة جيدة. لقد قمت الآن بتحديث موجز “ما الجديد” ليشمل هذا العنصر فقط للحالات التي ليست مستقرة (والتي تحتوي على الالتزام في latest الذي يفتح معرف Discourse). إذا قمت بتحديث موجز “ما الجديد”، فيجب ألا ترى هذا العنصر في حالتك المستقرة بعد الآن.
لدي بالفعل الإعدادات في الإعدادات، هل يجب أن يكون الإعداد متاحًا قبل تنفيذه؟
لا ينبغي أن يكون إعداد الموقع enable_discourse_id موجودًا لك. (تأكد من عدم الخلط بينه وبين enable_discourse_connect، فهذا شيء آخر.)
الآن بعد أن نظرت إلى مثيلك، أرى أخطاء http/https. لكي يعمل المعرف (ID)، يجب أن يكون الموقع تحت https. هذه على الأرجح مشكلتك.
… مثير للاهتمام، لكنني لا أفهم السبب. ربما لدينا فجوة مفاهيمية هنا: حاويات Discourse موجودة خلف مسرّع SSL، ولا يمكن الوصول إليها إلا عبر https. ولكن هذا للاتصال القياسي القادم من “الخارج” إلى “الداخل”. في حالة استخدام OAuth، تبدأ حاوية Discourse الاتصال من “الداخل” إلى مزود الهوية (IDP) الذي هو “خارج”. لا أرى أي خيار لتكوين هذا الاتصال بمعرف Discourse وإجباره على أن يكون “https”.
إذا قارنت هذا بإعدادات OIDC الكلاسيكية المستخدمة لتكوين OAuth مع مزود الهوية الخاص بي: هناك لدينا إعداد “وثيقة اكتشاف OpenID Connect”
https://....realms/[realm-name]/.well-known/openid-configuration
أعتقد أننا بحاجة إلى شيء مشابه لمعرف Discourse لتجنب المشاكل المتعلقة باتصالات https المفقودة. ملاحظة: مثيل الاختبار الخاص بي يحتوي على 3.6.0.beta2-latest، Commits · discourse/discourse · GitHub
