إعداد DiscourseConnect - تسجيل الدخول الموحد الرسمي لـ Discourse (sso)

[Discourse]

يُعد DiscourseConnect ميزة أساسية في Discourse تتيح لك تكوين “تسجيل الدخول الموحد (SSO)” لتفويض جميع عمليات تسجيل الدخول وتسجيل المستخدمين من Discourse بالكامل إلى موقع آخر. متوفر لعملائنا في خطط الاستضافة الاحترافية، التجارية، والمؤسسية.

(فبراير 2021) تم تغيير اسم “Discourse SSO” إلى “DiscourseConnect”. إذا كنت تشغل إصدارًا قديمًا من Discourse، فستُسمى الإعدادات أدناه sso_... بدلاً من discourse_connect_...

المشكلة

تود العديد من المواقع التي ترغب في التكامل مع موقع Discourse الاحتفاظ بجميع عمليات تسجيل المستخدمين في موقع منفصل. في مثل هذا الإعداد، يجب تفويض جميع عمليات تسجيل الدخول إلى ذلك الموقع الآخر.

ماذا لو أردت استخدام SSO بالتزامن مع مصادقة موجودة؟

الهدف من DiscourseConnect هو استبدال مصادقة Discourse. إذا كنت ترغب في إضافة مزود جديد، فراجع الإضافات الموجودة مثل: Discourse VK Authentication (vkontakte)

تمكين DiscourseConnect

لتمكين DiscourseConnect، يجب عليك ملء ثلاث إعدادات:

enable_discourse_connect: يجب تمكينه، وهو مفتاح عام.
discourse_connect_url: عنوان URL خارجي سيتم توجيه المستخدمين إليه عند محاولة تسجيل الدخول.
discourse_connect_secret: سلسلة سرية تُستخدم لتجزئة حمولات SSO. تضمن أصالة الحمولات.

بمجرد تعيين enable_discourse_connect إلى true:

• عند النقر على تسجيل الدخول أو الصورة الرمزية، سيتم إعادة توجيهك إلى /session/sso، والذي بدوره سيعيد توجيه المستخدمين إلى discourse_connect_url مع حمولة موقعة.
• لن يُسمح للمستخدمين بـ “تغيير كلمة المرور”. يتم إزالة هذا الحقل من ملف المستخدم.
• لن يتمكن المستخدمون بعد الآن من استخدام مصادقة Discourse (اسم المستخدم/كلمة المرور، Google، إلخ).

ماذا لو قمت بتفعيله بالخطأ؟

راجع: Log back in as admin after locking yourself out with read-only mode or an invalid SSO configuration

تنفيذ DiscourseConnect على موقعك

يستخدم Discourse عناوين البريد الإلكتروني لربط المستخدمين الخارجيين بمستخدمي Discourse، ويفترض أن عناوين البريد الإلكتروني الخارجية آمنة. إِذَا لَمْ تُعَزِّزَ صِحَّةَ عَوَازِلِ الْبَرِيدِ الْإِلِكْتُرُونِيِّ قَبْلَ إِرسالِهَا إِلَى DISCOURSE، فَموقعُكَ سَيَكُونُ شَدِيدَ الضَّعْفِ!

بدلاً من ذلك، إذا كنت مصراً على إرسال عناوين بريد إلكتروني غير معززة، تأكد من تعيين require_activation=true. هذا سيجبر جميع عناوين البريد الإلكتروني على التحقق من صحتها بواسطة Discourse. نُنصح بشدة بعدم القيام بذلك، لذا إذا واصلت معتمدين على هذا الإعداد، فإنك تتحمل مخاطر كبيرة.

سيقوم Discourse بإعادة توجيه العملاء إلى discourse_connect_url مع حمولة موقعة: (لنفترض أن discourse_connect_url هو https://somesite.com/sso)

ستستقبل حركة مرور واردة على النحو التالي:

https://somesite.com/sso?sso=PAYLOAD&sig=SIG

الحمولة هي سلسلة مشفرة بـ Base64 تتكون من nonce و return_sso_url. الحمولة هي دائمًا سلسلة استعلام صالحة.

على سبيل المثال، إذا كان الـ nonce هو ABCD، فسيكون raw_payload كالتالي:

nonce=ABCD&return_sso_url=https%3A%2F%2Fdiscourse_site%2Fsession%2Fsso_login، ويتم تشفير هذه الحمولة الخام بـ base 64.

يجب أن يقوم نقطة النهاية المستدعاة بما يلي:

1. التحقق من صحة التوقيع: تأكد من أن HMAC-SHA256 الخاص بـ PAYLOAD (باستخدام discourse_connect_secret كمفتاح) يساوي sig (سيكون sig مشفرًا بصيغة سداسية عشرية).
2. تنفيذ أي مصادقة مطلوبة.
3. إنشاء حمولة جديدة مشفرة بـ URL تحتوي على الأقل على nonce و email و external_id. يمكنك أيضًا تقديم بعض البيانات الإضافية، إليك قائمة بجميع المفاتيح التي سيفهمها Discourse:
   • يجب نسخ nonce من حمولة الإدخال.
   • يجب أن يكون email عنوان بريد إلكتروني معتمدًا. إذا لم يتم التحقق من عنوان البريد الإلكتروني، فقم بتعيين require_activation إلى “true”.
   • external_id هو أي سلسلة فريدة للمستخدم لن تتغير أبدًا، حتى لو تغير بريدُه الإلكتروني أو اسمه أو غيره. القيمة المقترحة هي رقم الصف ‘id’ في قاعدة بياناتك.
   • سيصبح username اسم المستخدم في Discourse إذا كان المستخدم جديدًا أو إذا تم تعيين SiteSetting.auth_overrides_username.
   • سيصبح name الاسم الكامل في Discourse إذا كان المستخدم جديدًا أو إذا تم تعيين SiteSetting.auth_overrides_name.
   • سيتم تحميل avatar_url وتعيينه كصورة رمزية للمستخدم إذا كان المستخدم جديدًا أو إذا تم تعيين SiteSetting.discourse_connect_overrides_avatar.
   • avatar_force_update هو حقل منطقي (boolean). إذا تم تعيينه إلى true، فسيفرض على Discourse تحديث الصورة الرمزية للمستخدم، سواء تغيرت avatar_url أم لا.
   • سيصبح bio محتوى السيرة الذاتية للمستخدم إذا كان المستخدم جديدًا، أو كانت سيرته الذاتية فارغة، أو تم تعيين SiteSetting.discourse_connect_overrides_bio.
   • سيُعد title لقب المستخدم.
   • سيُعد website موقع المستخدم في ملفه الشخصي.
   • سيُعد location موقع المستخدم في ملفه الشخصي.
   • سيتم تحميل profile_background_url وتعيينه كخلفية ملف المستخدم إذا كان المستخدم جديدًا أو إذا تم تعيين SiteSetting.discourse_connect_overrides_profile_background.
   • سيتم تحميل card_background_url وتعيينه كخلفية بطاقة المستخدم إذا كان المستخدم جديدًا أو إذا تم تعيين SiteSetting.discourse_connect_overrides_card_background.
   • سيُعد locale لغة المستخدم إذا كان المستخدم جديدًا وتم تمكين SiteSetting.allow_user_locale.
   • locale_force_update هو حقل منطقي. إذا تم تعيينه إلى true مع locale، فسيُجبر على تحديث اللغة للمستخدمين الحاليين (يتطلب SiteSetting.allow_user_locale).
   • الحقول المنطقية الإضافية (“true” أو “false”) هي: admin، moderator، suppress_welcome_message، logout.
4. قم بتشفير الحمولة بـ Base64.
5. احسب تجزئة HMAC-SHA256 للحمولة باستخدام discourse_connect_secret كمفتاح والحمولة المشفرة بـ Base64 كنص.
6. أعد التوجيه إلى return_sso_url مع معلمتي استعلام sso و sig (http://discourse_site/session/sso_login?sso=payload&sig=sig).

سيقوم Discourse بالتحقق من صحة الـ nonce، وإذا كان صالحًا، فسيستنفده فورًا حتى لا يمكن استخدامه مرة أخرى. ثم سيحاول:

1. تسجيل دخول المستخدم عن طريق البحث عن external_id مرتبط بالفعل في نموذج SingleSignOnRecord.
2. تسجيل دخول المستخدم باستخدام البريد الإلكتروني المقدم (تحديث external_id) (ما لم يكن require_activation = true).
3. إنشاء حساب جديد للمستخدم مع تقديم (البريد الإلكتروني، اسم المستخدم، الاسم) وتحديث external_id.

مخاوف أمنية

سيستنفد الـ nonce (الرمز لمرة واحدة) تلقائيًا بعد 30 دقيقة. هذا يعني أنه بمجرد إعادة توجيه المستخدم إلى موقعك، يكون لديه 30 دقيقة لتسجيل الدخول أو إنشاء حساب جديد.

البروتوكول آمن ضد هجمات إعادة التشغيل لأن الـ nonce يمكن استخدامه مرة واحدة فقط. يرتبط الـ nonce بجلسة المتصفح الحالية للحماية من هجمات CSRF.

تحديد عضوية المجموعات

إذا تم تحديد خيار discourse connect overrides groups، فسينظر Discourse في القائمة المفصولة بفواصل للمجموعات الممررة في groups.

بالإضافة إلى groups، يمكنك أيضًا تحديد عضوية المجموعات في حمولة SSO الخاصة بك باستخدام سمات add_groups و remove_groups بغض النظر عن خيار discourse connect overrides groups.

add_groups هي قائمة مفصولة بفواصل لأسماء المجموعات التي سنضمن أن المستخدم عضو فيها.
remove_groups هي قائمة مفصولة بفواصل لأسماء المجموعات التي سنضمن أن المستخدم ليس عضوًا فيها.

تنفيذ مرجعي

يحتوي Discourse على تنفيذ مرجعي لفئة SSO:

lib/discourse_connect_base.rb

سيكون التنفيذ التافه كالتالي:

class DiscourseSsoController < ApplicationController
  def sso
    secret = "MY_SECRET_STRING"
    sso = DiscourseApi::SingleSignOn.parse(request.query_string, secret)
    sso.email = "user@email.com"
    sso.name = "Bill Hicks"
    sso.username = "bill@hicks.com"
    sso.external_id = "123" # معرف فريد لكل مستخدم في تطبيقك
    sso.sso_secret = secret

    redirect_to sso.to_url("http://l.discourse/session/sso_login")
  end
end

الانتقال إلى تسجيل الدخول الموحد منه.

طالما لم يتم تعيين معامل require_activation إلى true في حمولة الطلب، فإن النظام يثق في عناوين البريد الإلكتروني المقدمة من نقطة نهاية تسجيل الدخول الموحد. هذا يعني أنه إذا كان لديك حساب موجود سابقًا في Discourse مع تعطيل DiscourseConnect، فسيقوم DiscourseConnect بإعادة استخدامه ببساطة وتجنب إنشاء حساب جديد.

إذا قمت بإيقاف تشغيل DiscourseConnect، فسيتمكن المستخدمون من إعادة تعيين كلمات المرور والحصول على الوصول إلى حساباتهم مرة أخرى.

مثال من العالم الحقيقي:

بافتراض الإعدادات التالية:

نطاق Discourse: http://discuss.example.com
عنوان URL الخاص بـ DiscourseConnect: http://www.example.com/discourse/sso
سر DiscourseConnect: d836444a9e4084d5b224a60c208dce14
تم التحقق من البريد الإلكتروني: لا (أضف require_activation=true إلى الحمولة)

محاولة مستخدم لتسجيل الدخول

• يتم إنشاء الـ nonce: cb68251eefb5211e58c00ff1395f0c0b

• يتم إنشاء الحمولة الخام: nonce=cb68251eefb5211e58c00ff1395f0c0b

• يتم تشفير الحمولة بـ Base64: bm9uY2U9Y2I2ODI1MWVlZmI1MjExZTU4YzAwZmYxMzk1ZjBjMGI=

• يتم تشفير الحمولة بـ URL: bm9uY2U9Y2I2ODI1MWVlZmI1MjExZTU4YzAwZmYxMzk1ZjBjMGI%3D

• يتم إنشاء HMAC-SHA256 على الحمولة المشفرة بـ Base64: 1ce1494f94484b6f6a092be9b15ccc1cdafb1f8460a3838fbb0e0883c4390471

أخيرًا، يتم إعادة توجيه المتصفح إلى:

http://www.example.com/discourse/sso?sso=bm9uY2U9Y2I2ODI1MWVlZmI1MjExZTU4YzAwZmYxMzk1ZjBjMGI%3D&sig=1ce1494f94484b6f6a092be9b15ccc1cdafb1f8460a3838fbb0e0883c4390471

في الطرف الآخر

1. يتم التحقق من الحمولة باستخدام HMAC-SHA256، إذا لم يتطابق التوقيع، تتوقف العملية.
2. عن طريق عكس الخطوات المذكورة أعلاه، يتم استخراج الـ nonce.

تسجيل دخول المستخدم:

name: sam
external_id: hello123
email: test@test.com
username: samsam
require_activation: true

يتم إنشاء حمولة غير موقعة:

nonce=cb68251eefb5211e58c00ff1395f0c0b&name=sam&username=samsam&email=test%40test.com&external_id=hello123&require_activation=true

الترتيب لا يهم، القيم مشفرة بـ URL

يتم تشفير الحمولة بـ Base64

bm9uY2U9Y2I2ODI1MWVlZmI1MjExZTU4YzAwZmYxMzk1ZjBjMGImbmFtZT1zYW0mdXNlcm5hbWU9c2Ftc2FtJmVtYWlsPXRlc3QlNDB0ZXN0LmNvbSZleHRlcm5hbF9pZD1oZWxsbzEyMyZyZXF1aXJlX2FjdGl2YXRpb249dHJ1ZQ==

يتم تشفير الحمولة بـ URL

bm9uY2U9Y2I2ODI1MWVlZmI1MjExZTU4YzAwZmYxMzk1ZjBjMGImbmFtZT1zYW0mdXNlcm5hbWU9c2Ftc2FtJmVtYWlsPXRlc3QlNDB0ZXN0LmNvbSZleHRlcm5hbF9pZD1oZWxsbzEyMyZyZXF1aXJlX2FjdGl2YXRpb249dHJ1ZQ%3D%3D

يتم توقيع الحمولة المشفرة بـ Base64

3d7e5ac755a87ae3ccf90272644ed2207984db03cf020377c8b92ff51be3abc3

يعيد المتصفح التوجيه إلى:

http://discuss.example.com/session/sso_login?sso=bm9uY2U9Y2I2ODI1MWVlZmI1MjExZTU4YzAwZmYxMzk1ZjBjMGImbmFtZT1zYW0mdXNlcm5hbWU9c2Ftc2FtJmVtYWlsPXRlc3QlNDB0ZXN0LmNvbSZleHRlcm5hbF9pZD1oZWxsbzEyMyZyZXF1aXJlX2FjdGl2YXRpb249dHJ1ZQ%3D%3D&sig=3d7e5ac755a87ae3ccf90272644ed2207984db03cf020377c8b92ff51be3abc3

مزامنة سجلات DiscourseConnect

يمكنك استخدام نقطة نهاية الإدارة POST /admin/users/sync_sso لمزامنة سجل DiscourseConnect، وتمرير نفس السجل الذي ستمرره إلى نقطة نهاية DiscourseConnect، ولا يهم الـ nonce.

إذا قمت باستدعاء admin/users/sync_sso من موقع آخر، فستحتاج إلى تضمين api_key إداري صالح و api_username صالح في رؤوس الطلب. راجع Sync DiscourseConnect user data with the sync_sso route لمزيد من التفاصيل حول كيفية هيكلة الطلب.

مسح سجلات DiscourseConnect

إذا تغيرت قيم external_id الخاصة بك من مزود DiscourseConnect (ربما قمت بتغيير خوارزمية التوليد، أو ربما هي نقطة نهاية مختلفة)، فيمكنك إزالة جميع السجلات الموجودة بأمان باستخدام وحدة تحكم rails:

SingleSignOnRecord.destroy_all

تسجيل خروج المستخدمين

يمكنك استخدام نقطة نهاية الإدارة POST /admin/users/{USER_ID}/log_out لتسجيل خروج أي مستخدم في النظام عند الحاجة.

لتكوين نقطة النهاية التي يعيد توجيه Discourse إليها عند تسجيل الخروج، ابحث عن إعداد logout redirect. إذا لم يتم تعيين أي عنوان URL هنا، فسيتم إعادة توجيهك إلى العنوان المكون في discourse connect url.

البحث عن المستخدمين حسب external_id

يمكن الوصول إلى بيانات ملف المستخدم باستخدام نقطة النهاية /users/by-external/{EXTERNAL_ID}.json. سيعيد هذا حمولة JSON تحتوي على معلومات المستخدم، بما في ذلك user_id الذي يمكن استخدامه مع نقطة نهاية log_out.

تنفيذات موجودة

• يمكن استخدام مكتبة discourse_api لـ SSO. راجع كود SSO في مجلد الأمثلة لرؤية تنفيذ أساسي.

• يجعل إضافة WordPress الخاصة بنا من السهل تكوين SSO بين WordPress و Discourse. توجد تفاصيل حول إعداده في علامة التبويب SSO في صفحة خيارات الإضافة.

عمل مستقبلي

• نود جمع المزيد من التنفيذات المرجعية لـ SSO على منصات أخرى. إذا كان لديك واحد، فيرجى النشر في فئة Dev / SSO.

ميزات متقدمة

• يمكنك تمرير حقول مخصصة للمستخدمين عن طريق إضافة بادئة custom لاسم الحقل. على سبيل المثال، يمكن استخدام custom.user_field_1 لتعيين قيمة UserCustomField التي تحمل الاسم user_field_1.
• يمكنك تمرير avatar_url لتجاوز الصورة الرمزية للمستخدم (يجب تمكين SiteSetting.discourse_connect_overrides_avatar). يتم تخزين الصور الرمزية مؤقتًا، لذا مرر avatar_force_update=true لإجبارها على التحديث إذا كان العنوان هو نفسه. حاليًا، لا يمكنك تمرير عنوان URL فارغ لتعطيل صورة المستخدم الرمزية.
• بشكل افتراضي، سيتم إرسال رسالة الترحيب إلى جميع المستخدمين الجدد المُنشأين عبر SSO. إذا كنت ترغب في قمع ذلك، فيمكنك تمرير suppress_welcome_message=true.
• لتكوين مثيل Discourse الخاص بك كمزود Discourse Connect، راجع: استخدام DiscourseConnect كمزود هوية.

تصحيح مشكلة مزود DiscourseConnect الخاص بك

لمساعدة في تصحيح مشكلة DiscourseConnect، يمكنك تمكين إعداد الموقع verbose_discourse_connect_logging. بتمكين هذا الإعداد، ستظهر تشخيصات غنية في YOURSITE.com/logs. تأكد من تحديد مربع warnings في أسفل YOURSITE.com/logs.

سنسجل تحذيرًا في السجلات مع تصدير كامل لحمولة SSO:

• في كل مرة يتم فيها بدء عملية DiscourseConnect، سنسجل تحذيرًا في السجل مع تصدير كامل لحمولة DiscourseConnect.

• في كل مرة يفشل فيها المستخدم في إكمال DiscourseConnect (بسبب انتهاء صلاحية الـ nonce أو حظر عنوان IP).

هل تحتاج إلى أتمتة تسجيلات المستخدمين؟ راجع Auto-provisioning user accounts when SSO is enabled

[dennisjbr]

مرحباً، من الصعب عليّ العثور على أي شيء، ولكن ما هو البروتوكول الذي يستخدمه هذا؟ هل نفترض أنه oauth2؟ لا تبدو المعلمات متطابقة، وأحصل على خطأ من المزود يبدو أنه يقبل معلمة sso=؟ ساعدني!

شكراً

[simon]

@dennisjbr

أي بروتوكول يستخدم هذا؟

DiscourseConnect هو تطبيق Discourse لـ SSO. لا يستخدم بروتوكولًا قياسيًا.

إذا كنت لا تمانع في النظر إلى كود PHP، فهناك مثال للتنفيذ هنا: wp-discourse/lib/sso-provider/discourse-sso.php at main · discourse/wp-discourse · GitHub.

@dennisjbr

هل تفترض أنه oauth2؟ المعلمات لا تبدو متطابقة

نعم، هذا لن ينجح. إذا كان لديك موفر OAuth2 ترغب في استخدامه للمصادقة على المستخدمين، فراجع المكون الإضافي Discourse OAuth2 Basic.

[dennisjbr]

شكراً @simon. هل رمز PHP هو مزود أيضًا، وليس مستهلكًا؟ رأيت أيضًا مزود OIDC قد يعمل وكذلك مزود “الوسيط” في منطقة الإضافات.

إذا كان مزود SSO غير قياسي، فمن/ما هو المقصود به إذا لم يكن متوافقًا مع الآخرين؟

شكرًا مرة أخرى!

[simon]

@dennisjbr

هل كود PHP هو مزود أيضًا، وليس مستهلكًا؟

الكود الذي ربطته هو لاستخدام ووردبريس كمزود للمصادقة لـ Discourse.

تسمح إضافة ووردبريس أيضًا باستخدام ووردبريس كعميل لـ DiscourseConnect: wp-discourse/lib/sso-client at main · discourse/wp-discourse · GitHub.

@dennisjbr

إذا كان مزود SSO غير قياسي، فمن/لماذا هو مخصص؟

لست متأكدًا من الدافع وراء إضافة تطبيق SSO مخصص إلى Discourse. أخمن أنه كان هناك سبب تجاري لذلك.

إحدى الفوائد التي يوفرها هي أنه يسمح بدمج موقع خارجي بشكل وثيق مع Discourse. على سبيل المثال، يمكن مزامنة جميع سمات المستخدم المدرجة هنا مع Discourse أثناء عملية المصادقة: discourse/lib/discourse_connect_base.rb at 7b89fdead98606d4f47ceb0a1d240d0f6e5f589e · discourse/discourse · GitHub.

كما يسمح باستخدام المواقع التي لم يتم تكوينها لتكون مزودات OAuth2 أو OpenID Connect لمصادقة المستخدمين على Discourse.

العيب هو أنه يتطلب إضافة بعض التعليمات البرمجية المخصصة إلى موقع مزود المصادقة.

[eric_wa]

مرحباً، أنا فضولي لمعرفة المشكلات المتعلقة بعدم التحقق من عناوين البريد الإلكتروني على موقع خارجي يوفر تسجيل الدخول الموحد (SSO). هل هو فقط أنه يتيح البريد العشوائي الآلي؟ أم أن هناك اعتبارات أخرى؟ لماذا لا يُنصح بأن يتعامل Discourse مع التحقق من البريد الإلكتروني إذا كان الموقع الخارجي لا يفعل ذلك؟

شكراً لأي رؤى إضافية.

[simon]

@eric_wa

هل الأمر يتعلق فقط بتمكين البريد العشوائي الآلي؟

أسوأ سيناريو أعرفه يتطلب هذه الشروط:

• لم يتم التحقق من عناوين البريد الإلكتروني على الموقع الخارجي
• لم يتم تعيين require_activation=true في حمولة SSO
• توجد حسابات حالية على موقع Discourse لا ترتبط بها SingleSignOnRecord (لم يسجل مالك الحساب في Discourse باستخدام SSO مطلقًا)

في هذه الحالة، يمكن لشخص ما التسجيل في الموقع الخارجي باستخدام عنوان البريد الإلكتروني الخاص بمستخدم Discourse الذي لم يسجل الدخول مطلقًا عبر SSO. سيسمح هذا للحساب غير المتحقق منه من الموقع الخارجي بالاستيلاء على حساب Discourse الذي يستخدم نفس عنوان البريد الإلكتروني. سيكون هذا مقلقًا بشكل خاص إذا كان حساب مسؤول على Discourse.

@eric_wa

لماذا لا يُنصح بأن يتولى Discourse التحقق من البريد الإلكتروني إذا لم يكن الموقع الخارجي يقوم بذلك؟

يُنصح بأن يتولى Discourse التحقق من البريد الإلكتروني إذا لم يكن الموقع الخارجي يقوم بذلك:

@Discourse

بدلاً من ذلك، إذا كنت تصر على إرسال رسائل بريد إلكتروني غير مصادق عليها، تأكد من تعيين require_activation=true، سيؤدي ذلك إلى إجبار Discourse على التحقق من صحة جميع رسائل البريد الإلكتروني. لا نزال ننصح بشدة بعدم القيام بذلك، لذلك إذا مضيت قدمًا مع تمكين هذا الإعداد، فأنت تتحمل مخاطر كبيرة.

هناك عدد قليل من الأسباب التي تجعل من الأفضل التعامل مع التحقق من البريد الإلكتروني على الموقع الخارجي:

• إجبار المستخدمين على تلقي البريد الإلكتروني التأكيدي من Discourse يضيف بعض الاحتكاك عند محاولة المستخدمين تسجيل الدخول إلى Discourse لأول مرة. (في الواقع، يجب أن يحدث هذا الاحتكاك في مكان ما - إما على جانب Discourse أو على جانب الموقع الخارجي.)
• لن يقوم Discourse بمطابقة حسابات Discourse الحالية مع تسجيلات الدخول الخارجية بناءً على عنوان البريد الإلكتروني إذا تم تعيين require_activation على true في حمولة SSO. هذه مشكلة إذا قمت بتمكين DiscourseConnect بعد إنشاء بعض الحسابات على Discourse عن طريق التسجيل باسم مستخدم / كلمة مرور. إنها أيضًا مشكلة إذا احتجت في أي وقت إلى حذف إدخالات SingleSignOnRecord على Discourse. لن يقوم Discourse بإنشاء إدخالات SingleSignOnRecord جديدة تلقائيًا عندما يحاول المستخدمون تسجيل الدخول مرة أخرى إلى Discourse.

[eric_wa]

شكراً لك، @simon - هذا مفيد جداً!

[GregorSondermeier]

مرحباً، لدي سؤال حول حقل groups في حمولة SSO.

@Discourse

تحديد عضوية المجموعة

إذا تم تحديد خيار Discourse Connect يتجاوز المجموعات، فسوف تأخذ Discourse في الاعتبار القائمة المفصولة بفواصل للمجموعات المقدمة في groups.

هل سيتم أيضاً تجاوز المجموعات الآلية (مثل المسؤولين والمشرفين ومستويات الثقة)؟ أم سيتم الاحتفاظ بها؟

[Firepup650 (Firepup Sixfifty)]

@GregorSondermeier

هل سيتم أيضاً الكتابة فوق المجموعات الآلية (مثل المسؤولين والمشرفين ومستويات الثقة)؟

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

[GregorSondermeier]

أتعلم… لم أر كلمة “يدوي” في الوصف. يبدو واعدًا لحالة الاستخدام الخاصة بي، سأجربه وأبلغكم بالنتائج.

[probablykasper (Kasper)]

عندما قرأت هذا، اعتقدت أنه كان من المفترض أن أقوم بإنشاء التوقيع مباشرة من الحمولة المشفرة بـ Base64. لم أدرك أنك بحاجة إلى إنشائه من بايتات UTF-8. هل يمكن توضيح ذلك؟

[martyn_thomas]

لقد كنت ألعب بـ DiscourseConnect - التوثيق رائع، شكرًا لكم.
ومع ذلك، لقد واجهت بعض العقبات التي آمل الحصول على بعض المساعدة/التوضيح بشأنها.

نريد أن يتمكن المستخدمون من تسجيل الدخول إلى ووردبريس باستخدام تسجيل دخول ديسكورس الخاص بهم (وهذا يعمل بشكل جيد ) - ومع ذلك.

• هل من الممكن إنشاء مستخدم ووردبريس عبر تسجيل ديسكورس (عندما ينشئ المستخدم حساب ديسكورس، يتم تلقائيًا إنشاء حساب/ملف تعريف ووردبريس لهم حتى يتمكنوا من تسجيل الدخول إلى ووردبريس)

• هل من الممكن مزامنة مجموعات مستخدمي ووردبريس ومجموعات ديسكورس.
  إذا كان لدى المستخدم حساب مستخدم في كل من ووردبريس وديسكورس، فإن DiscourseConnect قادر على ربطهما - ولكنه لا يمنح حساب ووردبريس مجموعات المستخدمين لمجموعات ديسكورس بنفس الاسم، والعكس صحيح (وماذا عن إذا لم يكن للمجموعات نفس الاسم - كيف يمكنني إخبار DiscourseConnect بمنح مجموعة المستخدمين “مجموعة اختبار” عندما يكون لدى المستخدم مجموعة ديسكورس “مجموعة لاختبار الأشياء”؟

ما الذي أفتقده؟

[Jagster (Jakke Flemming)]

لا أعرف الإجابة، ولكن…

@martyn_thomas

يقوم بإنشاء حساب/ملف شخصي لووردبريس لهم تلقائيًا

كن حذرًا بشأن ذلك. إنه في مكان غير قانوني ويعتبر ممارسة سيئة على نطاق واسع (باستثناء مالكي المواقع بالطبع ) لأنه سيحدث دون موافقة المستخدم ومعرفته، وفي نفس الوقت سيتم نقل البيانات إلى مكان آخر.

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

ولكن… لماذا؟ قصر تسجيل الدخول على Discourse SSO فقط من جانب ووردبريس وإعادة توجيه المستخدمين إلى Discourse لإنشاء الحساب وهذا كل شيء. ولكن على حد علمي، لا يمكنك مزامنة حسابات المستخدمين تلقائيًا فور إخراجها من الصندوق. ولماذا يجب عليك ذلك، لأنه مع SSO يحدث ذلك عندما يحتاجه المستخدم.

[martyn_thomas]

في السيناريو الخاص بنا (كمنظمة عضوية)

• يتم استخدام ووردبريس لإدارة الاشتراكات، وشراء العناصر من متجر ووردبريس، ونستخدم مجموعات المستخدمين لإدارة ما يمكن للعضو القيام به في المنظمة
• ديسكورس هو منتدانا/مجتمعنا عبر الإنترنت ونستخدم المجموعات للتحكم في المناطق التي يمكن للمستخدم الوصول إليها في ديسكورس)

حاليًا، يحتاج العضو الجديد إلى إعداد حساب ووردبريس (وإعداد اشتراكه وما إلى ذلك) وأيضًا إعداد حساب ديسكورس، ويتم إدارة/مزامنة مجموعات المستخدمين-مجموعات ديسكورس يدويًا.

أحاول إيجاد حل يقوم فيه المستخدم الجديد بإعداد مرة واحدة لإنشاء كلا الحسابين، ويتم مزامنة مجموعات المستخدمين-مجموعات ديسكورس تلقائيًا - أنا متأكد من أنني أستطيع حل مزامنة المجموعات باستخدام واجهات برمجة التطبيقات وما إلى ذلك. إنها إعدادات حساب المستخدم المتعدد التي أحاول حلها/تجنبها.

[simon]

@martyn_thomas

نريد أن يتمكن المستخدمون من تسجيل الدخول إلى ووردبريس باستخدام تسجيل الدخول الخاص بهم في ديسكورس

يبدو أن ما تفعله هو استخدام ديسكورس كموفر للمصادقة الأحادية (SSO) لووردبريس. هذا النهج موضح هنا: استخدام ديسكورس كموفر هوية (SSO، DiscourseConnect). يحتوي المكون الإضافي لووردبريس الخاص بديسكورس على خيارات لاستخدام ووردبريس كموفر للمصادقة الأحادية لديسكورس، أو لاستخدام ديسكورس كموفر هوية لووردبريس. يؤدي استخدام نفس الاسم لكلا النهجين إلى بعض الارتباك.

@martyn_thomas

في السيناريو الخاص بنا (كمنظمة عضوية)

• يتم استخدام ووردبريس لإدارة الاشتراكات، وشراء العناصر في متجر ووردبريس، ونستخدم مجموعات المستخدمين لإدارة ما يمكن للعضو القيام به في المنظمة
• ديسكورس هو منتدانا/مجتمعنا عبر الإنترنت ونستخدم المجموعات للتحكم في المناطق التي يمكن للمستخدم الوصول إليها في ديسكورس)

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

عند استخدام ووردبريس كموفر هوية لديسكورس، هناك عدد قليل من وظائف الأدوات المساعدة المفيدة لتعيين عضويات مجموعات ديسكورس للمستخدم بناءً على نشاطه في ووردبريس. تم توضيح هذه الوظائف هنا: إدارة عضوية المجموعة في ديسكورس باستخدام WP Discourse SSO.

بالعودة إلى سؤالك الأصلي:

@martyn_thomas

نريد أن يتمكن المستخدمون من تسجيل الدخول إلى ووردبريس باستخدام تسجيل الدخول الخاص بهم في ديسكورس (وهذا يعمل بشكل جيد ) - ومع ذلك.

• هل من الممكن إنشاء مستخدم ووردبريس عبر تسجيل ديسكورس (عندما ينشئ المستخدم حساب ديسكورس، فإنه ينشئ تلقائيًا حساب/ملف تعريف ووردبريس لهم حتى يتمكنوا من تسجيل الدخول إلى ووردبريس)

لقد مر وقت طويل منذ أن نظرت في كود عميل DiscourseConnect الخاص بالمكون الإضافي لووردبريس، ولكن أعتقد أن ما تطلبه هو أكثر أو أقل بالطريقة التي يتوقع بها هذا الكود العمل. إذا كان لدى المستخدم حساب ديسكورس، فكل ما يحتاجون إليه هو النقر على رابط “تسجيل الدخول عبر ديسكورس” في ووردبريس وسيتم إنشاء حساب لهم.

@martyn_thomas

هل من الممكن مزامنة مجموعات مستخدمي ووردبريس ومجموعات ديسكورس.

سيكون هذا ممكنًا تقنيًا عند استخدام ووردبريس كعميل DiscourseConnect، ولكن ما لم يتغير شيء ما، فلن تتمكن من استخدام طرق add_user_to_discourse_group و remove_user_from_discourse_group الموضحة في الوثائق التي ربطتها. ستحتاج إلى القيام بشيء مثل إعداد خطاف ويب (Webhook) لديسكورس يتم تشغيله عند إضافة مستخدم إلى مجموعة ديسكورس، ثم إضافة بعض التعليمات البرمجية في ووردبريس لمعالجة خطاف الويب هذا. لمزامنة المجموعات من ووردبريس إلى ديسكورس، ستحتاج إلى إجراء استدعاء API إلى ديسكورس لتحديث مجموعات المستخدم عند حدوث تغيير في ووردبريس. لذلك، قد يكون الشيء الذي يسهل تحقيقه نسبيًا إذا كنت تستخدم ووردبريس كموفر لـ DiscourseConnect معقدًا إلى حد ما إذا كنت تستخدم ووردبريس كعميل لـ DiscourseConnect.

[Jagster (Jakke Flemming)]

@simon

إذا كان لدى المستخدم حساب Discourse، فما عليه سوى النقر على رابط “تسجيل الدخول عبر Discourse” على WordPress وسيتم إنشاء حساب له.

باستثناء إذا تم استخدام تسجيل دخول مخصص، كما هو الحال عادةً مع WooCommerce/memberships/LLM التي تعرض هذا الزر وتفرض استخدام Discourse SSO كموفر وحيد، فهذا لا يحدث بشكل افتراضي ويتطلب بعض العمل المخصص.

[simon]

@Jagster

باستثناء حالة استخدام تسجيل الدخول المخصص، كما هو الحال عادةً مع WooCommerce/memberships/LLM

هناك عدد قليل من المشاكل المحتملة، واحدة تتعلق بالتخزين المؤقت وأخرى تتعلق بإعادة توجيه تسجيل الدخول التي تضيفها بعض الإضافات. يجب على أي شخص يواجه هذه المشاكل أن يسأل عنها في فئة Support > WordPress. عادة ما يتم حلها بسهولة.

[GregorSondermeier]

لقد نسيت تمامًا أن أبلغك: بالفعل يعمل تمامًا كما هو موصوف، وتتأثر المجموعات اليدوية فقط.

[Michael_Liu]

مرحباً @simon،
أعتقد أنني بحاجة ماسة إلى بعض المساعدة بشأن استجابة 404 من استكشاف إثبات المفهوم (POC) لهذه الميزة SSO. لقد كنت أعمل على هذه المشكلة ليوم كامل، لكنني ما زلت غير قادر على تحديد المشكلة. تمكنت من:

1. تمكين discourse_connect
2. تعيين discourse_connect_url إلى https:/ /localhost:4200/login
3. سر discourse-connect: 20’s (1) 1111111111111111111 لتبسيط الأمر.

ثم في صفحة تسجيل الدخول الخاصة بتطبيق Angular الخاص بي، أرسلت هذا الطلب باتباع الكود:

لكنني تلقيت استجابة 404 غير موجود.

لفهمي، أثناء إرسال طلب POST إلى نقطة نهاية admin/users/sync_sso، إذا لم يكن المستخدم موجودًا في discourse، فيجب عليه إنشاء مستخدم جديد بناءً على user_id والبريد الإلكتروني، ثم يجب أن تكون النتيجة المرتجعة كائن مستخدم وليس كائنًا فارغًا مع رمز الحالة 404.
لقد تحققت أيضًا من السجل ولم يقدم أي معلومات ذات صلة لهذه الاستجابة الفاشلة.

شكراً مقدماً!