مرحباً @balazsorban44، شكراً على التذكير بهذا. لقد قمت بمراجعة أولية لطلب السحب. إذا لم يكن لدى المؤلف وقت للعمل على هذه الأمور، فمن المحتمل أن نتمكن من تحملها. أتفق على أن دعم PKCE سيكون لطيفاً.
ومع ذلك، تجدر الإشارة إلى: لا أعتقد أن Discourse عرضة لهجمات “اعتراض رمز التفويض” التي يحمي منها PKCE. يتم المصادقة على Discourse دائماً في المتصفح عبر https، ولا يستخدم مخططات عناوين URL مخصصة على مستوى نظام التشغيل يمكن للتطبيقات الأخرى اعتراضها.
ولكن بالطبع، لا يضر إضافة طبقة إضافية من الأمان 
ليس بالضرورة القلق بشأن الأمان.
لقد عالجت الملاحظات هنا، مع الاحتفاظ بسجل المساهم الأصلي للاعتماد: feat: PKCE support by balazsorban44 · Pull Request #86 · discourse/discourse-openid-connect · GitHub
يسعدني إنهاء العمل عليه 
هل وجدت حلاً لهذا؟
للأسف لا.
@swt2c لقد قمت باختراقه في المكون الإضافي عن طريق إضافة
params << ["client_id", "<my-client-id>"]
params << ["logout_uri", post_logout_redirect] if post_logout_redirect
بعد السطر params << ["post_logout_redirect_uri", post_logout_redirect] if post_logout_redirect في plugin.rb.
سيكون من الرائع الحصول على دعم رسمي لهذا!
@balazsorban44 شكراً لتولي هذا الأمر! لقد قمت للتو بدمج طلب السحب، لذا أصبح لدينا الآن دعم PKCE اختياري في المكون الإضافي 
مرحباً كريس،
كيف قمت بدمج Authentik مع هذا المكون الإضافي؟ أي رؤى ستكون مفيدة. نحن نكافح منذ أسبوعين لجعله يعمل بشكل صحيح.
حسنًا، لا أتذكر شيئًا مميزًا. ما هي مشكلتك بالضبط؟ هل تريد مشاركة بعض لقطات الشاشة لتكوينك (ربما عبر رسالة خاصة)؟
شكرا على الرد يا كريس. بالتأكيد. سأتواصل معك لاحقًا هذا الأسبوع عندما يكون فريق التطوير الخاص بي متاحًا والذي كان يعمل على authentik. المشكلات الرئيسية تتعلق بالتدفق (flow) والخارج (outpost).
لدي مشكلة مثيرة للاهتمام، قبل النشر علنًا، أريد اختبار أن كل شيء يعمل، لذا فإن موفر OIDC الخاص بي مستضاف محليًا (شبكة فرعية خاصة) وغير متاح من الإنترنت.
للأسف، يفشل هذا لأن Discourse لا يسمح بالاتصال بعناوين IP الخاصة.
oidc.example.org يحل إلى عنوان IP خاص.
سجل OIDC: جلب وثيقة الاكتشاف من https://oidc.example.org/application/o/discourse/.well-known/openid-configuration
سجل OIDC: جلب وثيقة الاكتشاف أثار خطأ Faraday::ConnectionFailed FinalDestination: تم حظر جميع عناوين IP المحلولة
سجل OIDC: وثيقة الاكتشاف هي
---
(oidc) بدأت مرحلة الطلب.
(oidc) فشل المصادقة! openid_connect_discovery_error: OmniAuth::OpenIDConnect::DiscoveryError، وثيقة الاكتشاف مفقودة
أعتقد أنه نظرًا لأن openid_connect_discovery_document يمكن تغييره فقط بواسطة المسؤول، فيجب الوثوق به والسماح حتى بعناوين IP الخاصة.
يوجد إعداد موقع يسمى ‘allowed_internal_hosts’. إذا أضفت اسم المضيف الداخلي إلى تلك القائمة، فسيتم السماح بالطلبات إليه عبر كاشف SSRF.
في خدمات الاستضافة المشتركة (مثل الاستضافة الرسمية discourse.org)، لا يُوثق بالمسؤولين لإجراء طلبات داخل بيئة الاستضافة، وهذا هو سبب وجود هذا الحماية افتراضيًا.
عذرًا، لكنني لست متأكدًا من أنني أستطيع اتباع التعليمات لتثبيت الإضافة. أنا أستخدم Discourse في بيئة Docker المحلية الخاصة بي، ولا أستطيع حقًا العثور على ملف app.yml لإضافة التكوين.
قد يكون سؤالاً غبيًا، ولكن هل هناك دليل لتثبيت في بيئة تطوير محلية؟
بالنسبة لبيئة تطوير Docker، جرب التحقق تحت /var/discourse/containers/app.yml؟
ولكن، بالنسبة لتثبيتات التطوير غير Docker، انظر هنا:
المشكلة هي أنني لا أستطيع العثور على مجلد containers
بافتراض أنك اتبعت هذا الدليل، ربما اتبع هذا المنشور لتثبيت الإضافات؟
مرحباً.
لقد أضفت هذه الإضافة وهي تعمل بشكل جيد. المشكلة التي أراها هي أن تطبيق Discourse الخاص بنا لديه أسماء مستعارة، لذا يمكنني تسجيل الدخول بعنوان URL واحد. تم تكوين كليهما في Azure مع عناوين URL مناسبة للاستدعاء. لاحظت أن المكالمة إلى https://discourse.company.com/auth/oidc تُرجع عنوان URL للموقع مع عنوان URL المستعار، مثل https://login-blah-bla/authorize?client_id=&redirect_uri=https%3A%2F%[2Fdiscourse.us.company.com](http://2fdiscourse.us.company.com/)%2Fauth%2Foidc%2Fcallback.
ألا ينبغي أن يحترم عنوان URL الأصلي؟
هناك openid_connect_error_redirects ولكن أعتقد أن هذا في حالة حدوث أخطاء. أي فكرة كيف يمكنني تغيير إعادة التوجيه إلى السلطة (المعروفة أيضًا باسم discourse.company.com).
خلال تثبيت حزمي يدويًا، أحصل على هذا:
رسالة بعد التثبيت من oauth2:
لقد قمت بتثبيت إصدار oauth2 1.4.11، وهو إصدار نهاية دعمه.
لا يُتوقع دعم إضافي للسلسلة 1.4.x.
وتوصيات بالترقية إلى إصدار oauth2 2. سيكون من الأفضل عدم ظهور مثل هذه الرسائل، هل لديك خطط للترقية؟
كما أرى أن لديك:
لقد قمت بتثبيت oauth إصدار 1.1.0، مبروك!
الدعم غير التجاري للسلسلة 1.x سينتهي بحلول أبريل 2025. يرجى وضع خطة للترقية إلى الإصدار التالي قبل ذلك التاريخ.
الالتغيير الوحيد هو إلغاء دعم Ruby 2.7 وأي إصدارات أخرى ستصل أيضًا إلى نهاية عمرها الافتراضي بحلول ذلك الوقت.
لكن أعتقد أن هذا ليس “أنت”؟
مرحبًا،
خيار “السماح بتسجيلات جديدة” مطلوب بشكل صارم لتشغيل المكون الإضافي. يسمح هذا بإنشاء الحساب تلقائيًا عند الاتصال الأول بـ discourse ويعرض زر “تسجيل”. ولكن هل من الممكن السماح بتعطيله: أي عدم السماح للمستخدم الذي يتصل عبر openidconnect بتعديل معالم (parameters) حسابه وإنشاء حسابه مباشرةً. سيؤدي هذا إلى إزالة أزرار “تسجيل” المعروضة والتي لا ينبغي أن تكون موجودة في هذا السياق.
مع خالص التقدير
هل تمكنت من اكتشاف ذلك؟ أنا عالق على نفس الرسالة.
مرحبًا، هل تمكنت من إعداد هذا؟ لا أعرف لماذا أنا عالق تمامًا مع هذا، فمن بين مئات التطبيقات التي أدرتها باستخدام OpenID أو المصادقة، هذا هو الذي يسبب لي أكبر قدر من المتاعب.