إذا كنت ترغب يومًا في استخدام Discourse كمزود مصادقة، فقد أصبح ذلك ممكنًا الآن!
خلال الأسبوع الماضي، قمت بكتابة خدمة صغيرة يمكن استخدامها كمزود OpenID Connect/OAuth مع Discourse كواجهة خلفية.
يمكنك الاطلاع على الكود هنا:
لاحظ أن حالة الاستخدام الأساسية لدي كانت المصادقة على Nextcloud باستخدام Discourse، لذا قد لا تعمل لحالتك الخاصة.
إذا لم يكن شيء ما يعمل كما هو متوقع، أو إذا كان ينقصها تلك الميزة المحددة لجعلها تعمل بالنسبة لك، فلا تتردد في إنشاء مشكلة في مستودع GitHub.
مبادرة رائعة! لطالما أردت أن يكون Discourse قابلاً للاستخدام كمزود OAuth، حتى يمكن دمجه بسهولة مع المزيد من الأدوات. كما أن تحويله إلى خدمة خارجية صغيرة فكرة منطقية جداً!
أعجبني ما سمعته وأتمنى أن تقرر بعض المجتمعات تجربته!
أحب أن أرى دعم OIDC من قبل Discourse رسميًا بالإضافة إلى وظيفة Discourse Connect المخصصة لدينا، حتى نتمكن من تقديم حل جاهز للعملاء لدينا على المستويين القياسي والفرق دون الاعتماد على Okta أو ما شابه.
هذا رائع حقًا! شكرًا لك على القيام بذلك!
أود حقًا رؤية دمج هذا في Discourse بحيث يمكن أن يصبح مزود OIDC مستقل!
رائع، أنا أحب أنه يسمح بالوصول عبر المجموعات.
الخدمة Distrust هي خدمة منفصلة، لذا يجب نشرها كخدمة مستقلة. يمكنك تشغيلها داخل حاوية كما هو موضح في ملف README. لاحظ أنه للتشغيل الآمن، ستحتاج أيضًا إلى وكيل عكسي يتولى إنهاء SSL (قد أقوم بتنفيذ ذلك مباشرة في وقت ما في المستقبل).
آمل في الحصول على بعض الآراء الخبيرة حول المشكلات التي أواجهها أثناء محاولة استخدام Discourse كموفر SSO.
هدفي: أقوم بإعداد Discourse للتعامل مع المصادقة لتطبيق آخر (LibreChat). أستخدم وظيفة موفر DiscourseConnect القياسية، مع خدمة جسر OIDC distrust التي تعمل كعميل يتواصل مع Discourse.
المشكلة: يتدفق SSO بشكل مثالي حتى الخطوة الأخيرة. يتم إعادة توجيه المستخدم بشكل صحيح من تطبيقي إلى Discourse، ويمكنهم تسجيل الدخول بنجاح باستخدام بيانات اعتماد Discourse الخاصة بهم. ومع ذلك، بعد تسجيل الدخول، يتم إعادة توجيههم إلى الصفحة الرئيسية لمنتدى Discourse الخاص بي (/) بدلاً من return_sso_url الذي تم توفيره.
أين أنا عالق (ما استبعدته): لقد قمت باستكشاف هذه المشكلة لفترة طويلة وتأكدت من أنها ليست خطأ تكوين بسيطًا. لقد استبعدت بشكل قاطع ما يلي:
discourse connect provider secrets بشكل صحيح. أستخدم النطاق العادي (مثل auth.my-site.com) بدون أي بروتوكول، ويتطابق مفتاح السر تمامًا مع المفتاح الموجود في خدمة العميل الخاصة بي.enable discourse connect provider، وتم تعطيل إعدادات “SSO Client” غير الصحيحة.must_approve_users، وأن مستخدم الاختبار الخاص بي هو مسؤول لديه بريد إلكتروني تم التحقق منه بالكامل.الدليل الرئيسي: لدي دليلان قاطعان جعلااني في حيرة من أمري:
POST إلى /session لتسجيل الدخول بنجاح. يستجيب الخادم فورًا بإعادة توجيه 302 Found، ولكن رأس Location هو دائمًا /. هذا يثبت أن Discourse يقوم بإلغاء إعادة توجيه SSO عمدًا.production.log داخل الحاوية أثناء محاولة تسجيل الدخول. لا يتم كتابة أي شيء على الإطلاق في السجل أثناء هذه العملية. هذا يخبرني أن Discourse لا يعتبر هذا خطأ؛ إنه إجراء متعمد وصامت.سؤالي: نظرًا لأن تسجيل الدخول ناجح، ولكن إعادة التوجيه غير صحيحة ولا توجد أخطاء في السجلات، ما هي سياسة Discourse الداخلية أو فحص مسبق أو إعداد مخفي يمكن أن يتسبب في تجاهل return_sso_url وإعادة التوجيه إلى الصفحة الرئيسية بدلاً من ذلك؟ أشعر أنني استنفدت جميع الإعدادات القياسية.
شكرًا مقدمًا على أي أفكار!