تمكين تسجيل الدخول التلقائي للمجتمع المواجه للجمهور؟

لقد لاحظت بعض المشاركات حول هذا الموضوع، ومعظمها يقول إنها ميزة متاحة فقط للمجتمعات المغلقة تسجيل الدخول التلقائي باستخدام المكون الإضافي OpenId Connect و AWS Cognito - الدعم - Discourse Meta

كيفية تسجيل دخول المستخدم تلقائيًا في عرض الويب للتطبيق - مطور / sso - Discourse Meta

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

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

تعديل: على وجه الخصوص، أنا أتحدث عن هذا الجانب المحدد من مواصفات OIDC - Auto-sign-in with the OpenId Connect Plugin and AWS Cognito - #8 by david

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

يمكنك جعل الموقع مفتوحًا للمستخدمين المجهولين وجوجل.

إعجابَين (2)

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

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

شكرًا. لم أكن أعرف هذا. أنا مدير مجتمع أحاول فهم كل تفاصيل ثلاثة منتجات منفصلة وهذا يرهق عقلي لمحاولة فهم التفاصيل لكل منها! توقع رؤية عدد قليل من المشاركات الأخرى مني لمحاولة فرز كل شيء، وأشكرك على تحليك بالصبر.

إعجابَين (2)

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

هذا الموضوع قديم جدًا، لكن أعتقد أن المبدأ لا يزال ساريًا. بشكل أساسي، أضف عنوان URL مع دعم CORS المناسب الذي يعيد استجابة JSON تشير إلى ما إذا كان المستخدم لديه جلسة نشطة. ثم أضف بعض JavaScript إلى سمة Discourse الخاصة بك التي تستعلم عن عنوان URL هذا وتشغل عملية تسجيل الدخول الأحادي (SSO) إذا كانت هناك جلسة نشطة.

إعجابَين (2)

أخشى أن الإجابة العامة لا تزال إلى حد كبير كما كانت في المرة الأخيرة

المواصفات التي كنت أتحدث عنها هي إدارة جلسة OpenID Connect. للأسف، أصبح هذا الحل المستند إلى iframe أقل فائدة بشكل متزايد لأن العديد من المتصفحات الآن تمنع ملفات تعريف الارتباط الخاصة بالجهات الخارجية افتراضيًا. أصبح يعمل بشكل موثوق فقط إذا كان موفر الهوية الخاص بك و Discourse لهما نفس ‘الأصل’.

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

3 إعجابات

لكنني أعتقد أنني مخطئ.

أنت على حق تمامًا في أن النقر على “رد” سيؤدي إلى بدء تدفق تسجيل الدخول. وإذا تم استخدام DiscourseConnect (أو أي مزود تسجيل دخول واحد آخر)، فسيتم تخطي نافذة تسجيل الدخول الخاصة بـ Discourse :+1:

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

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

const cookie = require("discourse/lib/cookie").default;
if(cookie('name_of_example_com_auth_cookie') && !api.getCurrentUser()){
  // لدى المستخدم ملف تعريف ارتباط مصادقة لـ example.com. من شبه المؤكد أنهم
  // مسجلون الدخول هناك، لذا دعنا نبدأ تدفق المصادقة
  window.location = "https://forum.example.com/auth/oidc"
}

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

5 إعجابات

هذا هو الحال بالفعل. من الجيد معرفة أنه ممكن، ولكنه مخصص.

أيضًا، نظرًا لأنني لم أكن أعرف أن المستخدم الذي ينقر على “رد” سيتجاوز مربع حوار تسجيل الدخول اعتمادًا على التنفيذ، فإن هذا سيخفف الكثير من مخاوفي في المقام الأول. هذا هو الحاجز الرئيسي للدخول الذي أريد تجنبه، ويسعدني أنه يمكن تنفيذه.

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

إعجابَين (2)

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.