ليس لدي تثبيت Discourse محلي في الوقت الحالي، لذلك لست متأكدًا من مدى قدرتي على المساعدة.
استجابة 404 تجعلني أتساءل عما إذا كانت ميزة Discourse Connect ممكّنة بالفعل على موقع Discourse الخاص بك:
يبدو أنك تختبر هذا باستخدام تطبيق Angular محلي وموقع Discourse إنتاجي. أتوقع أن يعمل هذا بشكل جيد، ولكن ربما يسبب مشكلة. يجب أن تكون قادرًا بالتأكيد على الحصول على نوع من الاستجابة بخلاف 404.
@simon شكراً على ردك،
لقد تم تأكيد ذلك عدة مرات من قبلي،
ولدي أيضاً موقع اختبار إنتاجي مستضاف على النطاق الرئيسي لموقع ديسكورس هذا. إذا كان بإمكانك إلقاء نظرة على هذا [تم حذف الرابط]
لاختبار التدفق الإنتاجي، قمت بتحديث عنوان URL الخاص بـ Discourse Connect إلى “https://domainsite.com/login” فلا تتردد في تسجيل الدخول باستخدام مزود Google وإجراء اختبار. في سجل وحدة التحكم الفحص سترى الخطأ والاستجابة التي طبعتها، وهي 404.
بما أنني أقوم فقط بإثبات المفهوم (POC) إذا كنت لا تمانع، هل يمكنك ترك بريدك الإلكتروني لي حتى أتمكن من تعيينك كمسؤول للتحقيق في التكوينات على موقع ديسكورس الخاص بي عن كثب. مرة أخرى، أقدر حقًا وقتك ومساعدتك.
الجزء الوحيد الذي لست متأكدًا منه هو توقيع SIG و SSO، هل أقوم بذلك بشكل صحيح من خلال الكود؟
بالإضافة إلى ذلك، أنني جربت مفتاح API كلاهما، سواء كانت الإنشاء للجميع أو فقط للنظام، والنتائج هي نفسها. إذا أمكن، يرجى تزويدي بعينة تعمل لـ Postman أو رمز استنادًا إلى Angular.
فاتني هذا عندما نظرت لأول مرة إلى لقطة الشاشة لكودك:
mode: 'no-cors'
لست على دراية بتطبيقات Angular، ولكن يبدو أنك تحاول إجراء طلب API مصادق عليه إلى Discourse من العميل. لست متأكدًا من مكان حدوث ذلك في كود Discourse، ولكن فهمي هو أن Discourse يمنع طلبات API الإدارية التي تتم من العميل. هذا لأنه لا توجد طريقة لإجراء الطلب دون كشف مفتاح API على العميل. فيما يتعلق بذلك، يجب عليك تغيير مفتاح API الخاص بك الآن.
شكراً لتنبيهي،
يبدو وكأنها خطوة للأمام.
أنا أيضاً أحاول إرسال الطلب من Postman.
إذا كنت تعتقد أن الحظر من جانب العميل “mode: ‘no-cors’” لأن Discourse رفض قبول المكالمة بمفاتيح API من الواجهة الأمامية، فأعتقد أنه يجب أن يكون من المقبول إرسالها من Postman، هل هذا صحيح؟ ولكن النتيجة هي نفسها
لقد حاولت حتى بدء خادم ثم تشغيل الخادم لإرسال الطلب باستخدام مفتاح API من جانب الخادم، مما أعطى نفس النتيجة، مما جعلني أشعر وكأنني أفتقد بعض الإعدادات في موقع Discourse.
فكرة جيدة أن تجعل هذا يعمل من Postman، أو حتى من سطر الأوامر. من لقطة الشاشة التي نشرتها، يبدو أن لديك اسم مستخدم واجهة برمجة التطبيقات (api-username) ومفتاح واجهة برمجة التطبيقات (api-key) في نص الطلب. يجب أن تكون هذه المعلمات في رأس الطلب. يجب أن يحتوي نص الطلب على أزواج المفاتيح/القيم sig و sso. إذا كان ذلك مفيدًا، فإليك كيف يتعامل معها المكون الإضافي WP Discourse: wp-discourse/lib/plugin-utilities.php at main · discourse/wp-discourse · GitHub.
رائع! ها نحن ذا،
الآن يعمل!
1000 شكر @simon
كانت المشكلة كما ذكرت بالضبط:
يجب أن يكون sso و sig هما زوجا المفاتيح الوحيدان في الجسم
يجب أن يكون مفتاح api واسم مستخدم api في الرؤوس
كيف سيتصرف هذا إذا قمت بتشغيله على موقع لا يستخدم حاليًا external_id؟ هل سينجح في تسجيل دخول المستخدمين بناءً على بريدهم الإلكتروني فقط؟
بشكل عام، نظرًا لأن email و external_id هما الحقلان الإلزاميّان في الحمولة (payload)، هل يمكنك توضيح كيفية استخدامهما من جانب Discourse (عند تلقي الحمولة من الموقع الموثّق) لتحديد حساب المستخدم الذي سيتم تسجيل الدخول إليه؟
external_id مرتبط بالبريد الإلكتروني أثناء إنشاء المستخدم، هل سيستخدم البريد الإلكتروني ثم يربط external_id بهذا البريد الإلكتروني لتسجيلات الدخول المستقبلية؟email و external_id (كل منهما مرتبط بحساب Discourse مختلف)، هل سيستخدم external_id أو email لتحديد المستخدم الذي سيتم تسجيل الدخول إليه؟ أم سيحدث خطأ؟شكرًا لك!
أعتقد أن سؤالك الرئيسي يتعلق بالحقل external_id. تحتاج إلى تعيين حقل external_id في حمولة DiscourseConnect. يجب أن تكون قيمة الحقل عبارة عن سلسلة نصية مرتبطة بالمستخدم ولن تتغير أبدًا. أفترض أن تطبيقك يحتوي على جدول للمستخدمين. سيكون المفتاح الأساسي لإدخال المستخدم في هذا الجدول جيدًا لاستخدامه كقيمة للحقل external_id.
إذا أنشأ مستخدم حسابًا على Discourse قبل إضافة مصادقة DiscourseConnect من موقعك، فعند تسجيل الدخول لأول مرة إلى Discourse عبر DiscourseConnect، سيحاول Discourse العثور على المستخدم بناءً على عنوان البريد الإلكتروني الموجود في حمولة DiscourseConnect. بعد العثور على المستخدم، سيتم إضافة سجل إلى قاعدة بيانات Discourse يحتوي على external_id من حمولة DiscourseConnect. في المرة التالية التي يسجل فيها المستخدم الدخول، سيتم العثور عليه بواسطة external_id بدلاً من عنوان البريد الإلكتروني. (لاحظ أن هذا لا يعمل إذا قمت بتعيين المعلمة require_activation في حمولة DiscourseConnect إلى true.)
لدى Discourse آليات احتياطية جيدة لمعظم الحالات الاستثنائية. هناك مشكلات تتعلق بالمستخدمين الذين لديهم حسابات متعددة وعناوين بريد إلكتروني يمكن أن تؤدي إلى أخطاء. بعض التفاصيل حول التعامل مع هذه الحالات موجودة هنا: تصحيح الأخطاء وإصلاح مشكلات DiscourseConnect الشائعة.
مفيد جدا، شكرا لك! يبدو أن كل شيء يعمل كما توقعت 
لقد كنا نستخدم DiscourseConnect مع WordPress كمزود بنجاح لعدة سنوات ولم نغير تكوينات Discourse أو WP. اليوم لاحظت ما أعتقد أنه سلوك جديد.
عندما أسجل الخروج، كان يأخذني إلى شاشة تسجيل الدخول في WordPress. الآن يأخذني إلى شاشة تسجيل الدخول في Discourse. إذا حاولت تسجيل الدخول باستخدام شاشة Discourse، أحصل على خطأ غير معروف، ولكن النقطة هي أنني لا يجب أن أكون هناك على الإطلاق - يجب أن أكون عند تسجيل الدخول في WP.
لاحظ أنني قمت بتمكين تسجيل الدخول المحلي (لست متأكدًا من السبب، نظرًا لأنني أستخدم WP). إذا قمت بتعطيل تسجيل الدخول المحلي وحاولت تسجيل الدخول، فإنه يقول إنه لا توجد طرق تسجيل دخول متاحة. لذلك أعتقد أنه لا يعجبني اتصال WP الخاص بي، ولكن مرة أخرى، لم أقم بتغيير التكوينات على أي من الطرفين. لقد أكدت أن Discourse Connect ممكّن، وأن عنوان URL للاتصال صحيح، وأن السر هو نفسه على كلا الطرفين.
تم التحديث إلى 3.5.0.beta5-dev. أيضًا، فإن إضافة WP Discourse محدثة.
يحدث معي أيضاً، سأجرب الأمر لأرى إن كان بإمكاني إيجاد المشكلة.
نحن نستخدم أيضًا DiscourseConnect ونواجه نفس المشكلة.
لقد قمنا بتشغيله منذ بضع سنوات والآن وكل شيء سار بسلاسة. تم التحديث اليوم إلى 3.5.0.beta8-dev [e91024a221]
بشكل أساسي، يضيف رد الاتصال من نظام sso إلى عنوان URL الخاص بـ Discourse https://discourse.domain.ext/login ولدينا نفس الشاشة التي لدى @markschmucker.
لاحظنا أيضًا أنه عند النقر على شعار الرأس، نصل إلى https://discourse.domain.ext/ ويكون تسجيل الدخول ناجحًا (فقط نقرة على زر مطلوبة).
يبدو أنه في الإصدار السابق، كان وحدة تحكم الجلسة يتصرف بشكل مختلف، ومن المحتمل أنه فهم أن المكالمة بدأت بواسطة sso خارجي وكان يتعامل معها بالطريقة الصحيحة.
لاحظت أنه في الشهر الماضي، قام @zogstrip بارتكاب بعض التغييرات التي قد تكون مرتبطة (غير متأكد بنسبة 100٪) بسوء السلوك.
حتى الآن، قمنا بتطبيق حل بديل في طريقة رد الاتصال التي كانت تضيف /login إلى عنوان URL الخاص بـ Discourse ويبدو أن كل شيء يعمل بشكل صحيح.
إذا كنت أفتقد أي شيء مثل بعض المستندات التي كانت تقدم نصائح حول تغيير قد يكون معطلاً في جزء التعليمات البرمجية هذا، فأعلمني بذلك.
شكرًا لكم جميعًا على دعمكم.
@markschmucker، @jimkleiber، و @marco.palumbo هل تواجهون نفس المشكلة الموضحة في https://meta.discourse.org/t/no-login-methods-when-using-discourse-connect-only/373504؟
إذا كان الأمر كذلك، فإن الحل هو التأكد من تمكين إعداد الموقع “المصادقة فورًا”.
لدي تمكين “المصادقة فورًا”.
شكراً لمساعدتك في هذا @zogstrip. للأسف، إذا قمت بتمكين “المصادقة فوراً”، فإنني أفقد القدرة على وجود صفحة “ترحيب” للمستخدمين المجهولين.
لا يبدو أنه من الممكن إزالة اسم أو avatar_url باستخدام DiscourseConnect SSO. لقد حاولت تعيين الحقول إلى سلسلة فارغة (تم التأكيد على سبيل المثال أن avatar_url= ينتهي به المطاف في معلمة sso المشفرة بـ base64)، ولكنني أعتقد أن الكود يتجاهل الحقول الفارغة.
الأسماء والصور اختيارية في نظامي، ولكن بالطريقة التي يعمل بها هذا الآن، بمجرد تعيينها، لا يمكن إلغاؤها أبدًا، فقط استبدالها. هل هناك فرصة أنني أفعل شيئًا خاطئًا؟ (إذا لم يكن الأمر كذلك، فربما يمكن إصلاح هذا؟)
[تعديل]: لقد بحثت بالفعل عن إجابة، ولكن بالطبع في اللحظة التي نشرت فيها ما سبق، حاولت البحث عن كلمات مفتاحية مختلفة ووجدت Allow name removal using SSO - #9 by mentalstring. لقد صوتت لصالح ذلك ولكنني لا أرفع آمالي. 
أواجه نفس مشكلة إعادة توجيه تسجيل الدخول التي يصفها @markschmucker و @jimkleiber و @marco.palumbo أعلاه، والتي اكتشفتها قبل بضعة أسابيع وعرفت أنها كانت تعمل بشكل صحيح في وقت ما في مايو. قراءة ما قلته عنها أعلاه يجعلني مقتنعًا بأنها مشكلة تراجعية في Discourse تم تقديمها في تحديث ما من مايو، لأنها أصابتنا جميعًا في نفس الوقت، وكان لدينا جميعًا رمز SSO يعمل، ولا نشترك في أي رمز SSO مشترك.
لقد نشرت تقرير خطأ على أمل أن نتمكن من إصلاح هذا.
تم إصلاح مشكلة إعادة التوجيه بالنسبة لي في الإصدار 3.6.0-beta1.
@markschmucker و @marco.palumbo
يبدو أن هذا تم إصلاحه قبل بضعة أسابيع ويجب أن يعمل بشكل صحيح مرة أخرى في v3.6.0.beta1.