هذا سؤال قديم، لكن حدثت بعض التغييرات منذ طرحه في عام 2015. أحد التغييرات البارزة هو أننا نستخدم الآن مصطلح DiscourseConnect بدلاً من Discourse SSO. والسبب في ذلك هو أن مصطلح SSO يمكن أن يُستخدم للإشارة إلى عدة آليات مصادقة مختلفة (مثل SAML، وOAuth2، وAuth0…). أما DiscourseConnect فهو تنفيذ Discourse لبروتوكول SSO.
عند تمكين DiscourseConnect، ستتم جميع عمليات المصادقة على موقع Discourse على الموقع الذي تحدده عبر إعداد الموقع discourse connect url. وهذا يعني أن المستخدمين سينشئون حساباتهم عن طريق التسجيل على موقعك الخارجي بدلاً من التسجيل على Discourse. وسيتم نقل تفاصيل الحساب إلى Discourse عند تسجيل دخول المستخدمين عبر DiscourseConnect. وعند تسجيل دخول المستخدمين إلى Discourse لأول مرة، ستُحدَّد تفاصيل حساباتهم بناءً على البيانات المقدمة في حمولة SSO. وبالنسبة لبعض إعدادات موقع Discourse، قد تستمر تفاصيل الحساب في المزامنة في كل مرة يسجل فيها المستخدم دخوله إلى Discourse، أو قد يتمكن المستخدمون من تعيين قيم مميزة لحسابهم على Discourse. والإعدادات ذات الصلة بذلك هي:
auth overrides emailauth overrides usernameauth overrides namediscourse connect overrides biodiscourse connect overrides avatardiscourse connect overrides profile backgrounddiscourse connect overrides locationdiscourse connect overrides websitediscourse connect overrides card backgrounddiscourse connect overrides groups
لاحظ أنه افتراضيًا، يرسل مكون WP Discourse فقط الحقول التالية في الحمولة:
usernameemailnamebioavatar_url
يمكن إضافة معاملات إضافية إلى الحمولة عن طريق الربط بمرشح wpdc_sso_params الخاص بمكون WP Discourse.
ربما تكون أكبر وظيفة تُفقد عند تمكين DiscourseConnect هي أنه عند التفعيل، يصبح هو طريقة المصادقة الوحيدة للموقع. وهذا يعني أنه لا يمكن تمكين تسجيل الدخول عبر الشبكات الاجتماعية على Discourse بالتزامن مع DiscourseConnect. ومع ذلك، يمكنك تمكين تسجيل الدخول عبر الشبكات الاجتماعية على موقع مزود المصادقة الخاص بك. على سبيل المثال، يمكنك السماح للمستخدمين بتسجيل الدخول إلى موقعك الإلكتروني عبر مزودي تسجيل الدخول عبر الشبكات الاجتماعية المختلفة، ثم السماح لهم بتسجيل الدخول إلى Discourse عبر DiscourseConnect. ويمكن اتباع نهج مشابه مع OAuth2 أو SAML. حيث يمكن للمستخدمين تسجيل الدخول إلى موقعك الإلكتروني باستخدام طرق المصادقة تلك، ثم إعادة توجيههم إلى Discourse لتسجيل الدخول عبر DiscourseConnect.
وظيفة أخرى تُفقد هي أنه لا يمكن تمكين إعداد الموقع invite only الخاص بـ Discourse بالتزامن مع DiscourseConnect.
تتمثل إحدى الفوائد الكبيرة في القدرة على مزامنة بيانات المستخدمين بسهولة من تطبيق خارجي إلى Discourse. ويمكن تعيين عضويات المجموعات في Discourse بسهولة باستخدام الحقول add_groups وremove_groups التي تُمرَّر في حمولة SSO. ولا يرسل مكون WP Discourse هذين الحقلين افتراضيًا، لكن يمكن إضافتهما إلى الحمولة عن طريق الربط بمرشح wpdc_sso_params الخاص بمكون WP Discourse.
يمكن أيضًا مزامنة عضويات المجموعات وأي حقول أخرى يمكن تعيينها في الحمولة عبر طلب في الخلفية. لمزيد من التفاصيل، راجع مزامنة بيانات مستخدم DiscourseConnect مع مسار sync_sso. ولمزيد من التفاصيل حول مزامنة المجموعات باستخدام مكون WP Discourse، راجع إدارة عضوية المجموعات في Discourse باستخدام WP Discourse SSO.
ربما تكون الفائدة الأخرى هي أنه إذا كان لديك بالفعل قاعدة مستخدمين كبيرة على موقع خارجي، فإن تمكين DiscourseConnect سيمكن هؤلاء المستخدمين من تسجيل الدخول إلى Discourse دون الحاجة إلى إنشاء حساب منفصل على Discourse.
مع DiscourseConnect، يتم ربط الحسابات بناءً على external_id الذي يُمرَّر من موقع مزود SSO إلى Discourse. ويستخدم مكون WP Discourse معرف WordPress الخاص بالمستخدم كقيمة لـ external_id.
نعم، افتراضيًا تُحدَّد جميع هذه الحقول باستخدام تنفيذ WP Discourse لـ DiscourseConnect. وكما ذُكر أعلاه، يعتمد ما إذا كانت هذه الحقول ستستمر في المزامنة في كل مرة يسجل فيها المستخدم دخوله إلى Discourse على قيمة إعدادات موقع Discourse المختلفة.