لقد قمت للتو بإعداد مثيل من Discourse وأضفت discourse-openid-connect إليه، مع ربط Keycloak كمزود OIDC.
بعد اتباع الشروط الثلاثة المذكورة هنا مع تحديث حديث، أواجه سلوكًا يتطلب المصادقة عبر Keycloak، أو إذا كنت قد سجلت الدخول بالفعل، فإن النقر على زر “تسجيل الدخول” سيطلب مني “إنشاء حساب جديد” مع ملء الحقول المستمدة من معلومات Keycloak الخاصة بالمستخدم.
هل توجد طريقة لتجاوز هذه الخطوة التي تتطلب إجراءً إضافيًا من المستخدم؟ هذه الحقول مملوءة بالفعل تلقائيًا من Keycloak، لذا لا ينبغي أن يكون هناك حاجة للمستخدم لتعديلها خصيصًا لـ Discourse.
هل يجب أن تتم عملية إنشاء الحساب ضمنيًا، على غرار ما تفعله Grafana؟ هدفي هو أن تدعم كل خدمة يقدمها المجتمع هذه التجربة السلسة، بحيث يكون حساب المجتمع الأصلي الذي تم تسجيله هو كل ما يحتاج المستخدم للتعامل معه.
قد لا يبدو هذا منطقيًا إذا كنت تفكر في المصادقة الخارجية مثل Google أو Facebook أو Github وما إلى ذلك. يمكن للمستخدم تسجيل حسابه في المجتمع عبر Keycloak باستخدام إحدى هذه المنصات، لكن Keycloak نفسه، الذي يُستخدم داخليًا فقط، هو ما يُفترض أن يعمل مع جميع الخدمات الفردية، لذا فإن الموافقة الضمنية/التلقائية والتسجيل التلقائي أمر مرغوب فيه.
أنا جديد في منصة Discourse، وقد قمت بإعداد ومزود SSO OAUTH2 الخاص بي بنجاح. المستخدمون الجدد يرون شاشة التأكيد عند وصولهم لأول مرة وتسجيل دخولهم إلى Discourse. كيف يمكنني تبسيط هذه العملية وجعل إنشاء حساب المستخدم تلقائيًا؟ القيم المعروضة في تلك الشاشة صحيحة وتظهر مرة واحدة فقط. ما الذي يمكنني فعله لإزالة هذه الشاشة وتبسيط عملية إنشاء الحسابات لمستخدمي مجتمعي؟
هذا غير ممكن حاليًا. عندما ينشئ المستخدمون حسابًا لأول مرة، سيتعين عليهم النقر على زر “إنشاء حساب جديد” في نموذج التسجيل.
السلوك الذي تبحث عنه مشابه لكيفية عمل تطبيق Discourse للنظام الموحد لتسجيل الدخول (SSO). في هذه الحالة، يتم إنشاء الحسابات في الخلفية دون أن يملأ المستخدم نموذج التسجيل. يبدو أنه من الممكن تنفيذ وظيفة مماثلة لتسجيل الدخول عبر OAuth2، ولكن قد تكون هناك حالات لا يتم فيها تمرير معلومات كافية من مزود OAuth2 لإنشاء حساب.
لم أقضِ الكثير من الوقت في هذا منذ نشرتي هنا، لكنني في النهاية اعتمدت ميزة SSO الخاصة بـ Discourse لاستخدام خدمة جسرية صادفتها لـ OpenID-Connect. كانت خدمة بلغة Python تحتوي على حاوية Docker، مما جعل النشر أسهل مع إعداد docker-compose الخاص بي.
لذا، وفّر Keycloak الحساب المسجّل مسبقًا والمُشغّل، وعند زيارة Discourse، كان يتم تسجيل المستخدم تلقائيًا باستخدام التفاصيل المقدمة من الجسر، حسب ما أذكر. لقد مرّ وقت طويل منذ تعاملت مع هذا، لكن كانت هذه العملية أفضل قليلًا من دعم OAuth/OpenID-Connect في Discourse، حسب علمي (على الأقل في ذلك الوقت، لم أتحقق مما إذا تم تحسينه منذ ذلك الحين).
على أي حال، لا تتم مزامنة تفاصيل الحساب كما هو متوقع. يحتاج المستخدم إلى تسجيل الخروج من Discourse ثم الدخول مرة أخرى لحدوث أي مزامنة، وحتى في هذه الحالة، أعتقد أن هناك بعض العناصر التي لا يمكن مزامنتها من مزوّد SSO إلى Discourse (مثل المجموعات/الأدوار، أو شيء مشابه، حسب ما أذكر، كانت هناك بعض المشاكل).
ستحتاج إلى اكتشاف تحديث تفاصيل المستخدم من المزوّد لتحديث Discourse عبر واجهات برمجية (APIs) الخاصة به، حسب ظني، لتحقيق إعداد مزامنة صحيح. وإلا فقد تواجه تفاصيل مكررة غير متزامنة، أو مزامنة مربكة للمستخدمين.
لذا، أعتقد أنه إذا كانت تكامل SSO عبر OAuth2 الذي تملكه حاليًا ليس ميزة SSO الخاصة بـ Discourse التي تتطلب عادةً جسر SSO، حسب علمي، بل البديل المكون من إضافة، فإن التحول إلى النسخة غير المكونة من إضافة مع جسر SSO سيوفر لك التجربة المرغوبة، حسب ما أذكر.
لقد أضفت للتو بعض إعدادات الموقع الجديدة التي ستساعد في ذلك. لتخطي شاشة ‘إنشاء حساب جديد’، قم بتفعيل sso_overrides_username، و sso_overrides_email، و sso_overrides_name.
يوجد بالفعل حساب تم إنشاؤه باسم test__EMAIL__ في نظامنا (Discourse)
إذا قمت بتسجيل الدخول باستخدام OpenID واسم المستخدم: test، والبريد الإلكتروني: test__EMAIL__
ستظهر نافذة “حساب جديد” تطلب منك اسم مستخدم جديد (test1) وبريد إلكتروني جديد (test__EMAIL__)
هل يوفّر موفّر OpenID Connect الخاص بك التحقق من بريد المستخدمين الإلكتروني؟ يمكننا فقط ‘الاعتماد’ على البريد الإلكتروني القادم من OIDC إذا كان قد تم التحقق منه، وتم تعيين القيمة المنطقية للتحقق بشكل صحيح.
@David، لدينا الإصدار 2.5.2 المستقر - وهذا الخيار غير موجود… هل يمكن نقل هذا الخيار إلى الفرع المستقر؟ نحن بحاجة إليه، لكننا لا نستخدم في الإنتاج سوى الفرع المستقر…
