Hi… I’ve searched / browsed this forum but couldn’t find a simple explanation. Is multisite a feature where you want multiple separate sites but on the same server?
What I’m really looking for / wondering is if you can set up multiple forums on the same server, that share the same user database? Sorry if this has already been asked.
To share the userbase, simply have one of the forums be the sso provider and have the other forums be an sso consumer.
Note that this is visible to the user: When they want to log in, they always go to the same site. This could be confusing, depending on the use case. If you want to avoid that, you need to set up an external SSO provider.
Also note that this will share the credentials, but not the user profiles, group memberships, …
Profile stuff can be handled in the payload.
Related:
https://meta.discourse.org/t/can-multisite-instances-communicate-with-one-another/8984?u=erlend_sh
Are there any newer/better approaches to this since the last post? This is something we want to do as well.
We definitely want to share user profiles so that badges (for example) only have to be earned once overall, not once per site.
Using discourse in multiple sites with shared accounts? suggests that just SSO will do the trick but Multiple sites with the same user accounts? suggests that using SSO just takes care of the authentication (credentials) but nothing else.
If you want shared badges, like using the sum for each site to get a badge, you gotta use a single forum and categories to separate stuff.
إذن، ما هي أفضل طريقة للتعامل مع هذا؟ هل تقوم بإعداد موقع رئيسي مركزي وتضمين روابط Discourse في مواقع أخرى (بحيث تكون منشورات المناقشة مخزنة فعليًا “على” الموقع المركزي)؟
“الأفضل” أمر نسبي ما لم تحدد قدراتك.
الأسهل هو بالضبط ما ورد في المنشور أعلاه: استخدام مثيل واحد فقط.
إذا توفرت لديك القدرات الهندسية، أو الميزانية المكافئة، فيمكنك تشغيل عدة أمثلة تشارك نظام دخول واحد موحد (SSO)، مع تطبيق مصاحب يستعلم عن جميع أمثلة Discourse الشقيقة للحصول على البيانات، ومنح المستخدمين شارة في كل مثيل عبر استدعاءات واجهة برمجة التطبيقات (API).
إذن، هو في الأساس إضافة لمزامنة ملفات تعريف الدخول الموحد (SSO). هل تعلم بوجود أي شيء مشابه من هذا القبيل؟ هل يعمل أي شخص بالفعل على شيء مماثل؟ أنا مهتم أيضًا.
قرأت أن طرق تسجيل الدخول البديلة مثل فيسبوك تُفقد عند استخدام الدخول الموحد (SSO). هل لا يزال الأمر كذلك حتى اليوم؟ هل لن يحتوي موقع Discourse المركزي على تلك طرق تسجيل الدخول البديلة أيضًا؟ لماذا يحدث ذلك؟
يمكنك إعداد أحد مواقع Discourse كموقع أساسي، وإعداد المواقع الأخرى لاستخدام الموقع الأساسي كخادم SSO. في هذه الحالة، يمكن للموقع الأساسي استخدام تسجيل الدخول عبر الشبكات الاجتماعية، بينما ستقوم المواقع التي تستخدمه كخادم SSO بإعادة توجيه جميع عمليات تسجيل الدخول إلى الخادم الأساسي.
إذا كنت تستخدم SSO، فستكون هي طريقة المصادقة الوحيدة المتاحة لك. أما إذا كنت ترغب في تفويض أمثل إلى خادم آخر، فيجب أن تستخدم OAuth2.
ماذا يحدث عندما يحاول مستخدم من منتدى Discourse تابع (Slave) تسجيل الدخول؟ يتم توجيهه إلى إنشاء حساب في المنتدى الرئيسي (Master) الذي يشمل خيارات تسجيل الدخول عبر وسائل التواصل الاجتماعي التي أختارها، ثم يُعاد توجيهه إلى المنتدى التابع ليُطلب منه تسجيل الدخول. ولكن ما هي بيانات الاعتماد المطلوبة إذا استخدم تسجيل الدخول عبر وسائل التواصل الاجتماعي مثل فيسبوك بعد نجاح إنشاء الحساب؟ آسف على طول السؤال، يمكنني إعادة صياغته إذا لم يكن واضحًا… باختصار، شبكة Discourse تعتمد على المنتدى الرئيسي الذي يسمح بتسجيل الدخول عبر وسائل التواصل الاجتماعي، فهل تستخدم المنتديات التابعة المصادقة المحلية المخزنة في المنتدى الرئيسي أم أنها لا تزال تعتمد على مصادقة فيسبوك مثلًا؟ يبدو أن هذا قد يسبب ارتباكًا لمدير كلمات المرور المحلي.
ملخص سريع: أريد أن يسمح كل من المنتدى الرئيسي والمنتديات التابعة بتسجيل الدخول عبر وسائل التواصل الاجتماعي.
يتم إعادة توجيه العميل إلى الخطاب الأساسي. يقوم بالتحقق من الهوية. هذا هو المكان الذي يسجل فيه المستخدمون الدخول. يمكنه استخدام وسائل التواصل الاجتماعي.
لا تعرف مواقع الخطاب الخاصة بالعميل ما إذا كان المستخدم قد استخدم وسائل التواصل الاجتماعي عند تسجيل الدخول (على الأقل لا أعتقد ذلك).
إذن، عندما يسجل الضيف الدخول على الخادم التابع، يتم إعادة توجيهه إلى الخادم الرئيسي حيث يسجل الدخول عبر وسائل التواصل الاجتماعي، ثم يُعاد توجيهه مرة أخرى إلى الخادم التابع وهو مسجل الدخول؟