I’m considering the WP-Discourse plugin to integrate my WP site with Discourse, but would be interested in understanding a bit better what the benefits and costs are. What do you lose exactly when you turn on SSO in terms of discourse functionality, and what do you gain? How are the WP and Discourse accounts linked? For example, can the user profile info like picture, username, email address, “about me” and location be shared across both platforms?
Thanks for any guidance. I’d love to be directed also any good examples of the wp-discourse plugin in action, with and without SSO.
هذا سؤال قديم، لكن حدثت بعض التغييرات منذ طرحه في عام 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 email
auth overrides username
auth overrides name
discourse connect overrides bio
discourse connect overrides avatar
discourse connect overrides profile background
discourse connect overrides location
discourse connect overrides website
discourse connect overrides card background
discourse connect overrides groups
لاحظ أنه افتراضيًا، يرسل مكون WP Discourse فقط الحقول التالية في الحمولة:
username
email
name
bio
avatar_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 سيمكن هؤلاء المستخدمين من تسجيل الدخول إلى Discourse دون الحاجة إلى إنشاء حساب منفصل على Discourse.
مع DiscourseConnect، يتم ربط الحسابات بناءً على external_id الذي يُمرَّر من موقع مزود SSO إلى Discourse. ويستخدم مكون WP Discourse معرف WordPress الخاص بالمستخدم كقيمة لـ external_id.
نعم، افتراضيًا تُحدَّد جميع هذه الحقول باستخدام تنفيذ WP Discourse لـ DiscourseConnect. وكما ذُكر أعلاه، يعتمد ما إذا كانت هذه الحقول ستستمر في المزامنة في كل مرة يسجل فيها المستخدم دخوله إلى Discourse على قيمة إعدادات موقع Discourse المختلفة.