التكامل مع نظام مصادقة مخصص حيث لا تكون البريد الإلكتروني فريدًا

[Moin]

هذا بالضبط ما كان يدور في ذهني أيضًا.
سأقوم بتضمين الرابط للموضوع Category Group Review/Moderation حيث واجهت صعوبة في البداية في العثور عليه من خلال البحث.
أواجه دائمًا صعوبة في العثور على Documentation في فئة Announcements

[supermathie (Michael Brown)]

@jonbarrow

يمكننا حصر هذا في 5 من مطورينا فقط، مما يتناسب مع تلك الحدود، ولكنه سيتطلب منا تحديد من يحصل على حقوق كاملة في المنتدى ومن لا يحصل عليها.

بصراحة، هذه ربما فكرة جيدة بغض النظر عن ذلك، يمتلك المسؤولون (Admins) جميع الحقوق (تنزيل النسخ الاحتياطية، رؤية/تغيير أسرار التكوين، رؤية البيانات الشخصية للأشخاص، الوصول إلى الرسائل الشخصية، …) ومن الأفضل إبقاء هذه الدائرة ضيقة.

هناك مجال كبير لـ “الامتيازات العالية” دون أن تكون مسؤولاً كاملاً.

[jonbarrow (Jonathan Barrow)]

@Firepup650

أعتقد أن مديري الفئة (TL4) يمكنهم المساعدة هنا بشكل كبير.

@Moin

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

أواجه دائمًا صعوبة في العثور على Documentation في فئة Announcements

شكراً لكما على هذا، لم أكن أعلم أن هذا شيء منفصل!

@supermathie

بصراحة، هذه ربما فكرة جيدة بغض النظر، يمتلك المسؤولون (Admins) كل الحقوق (تنزيل النسخ الاحتياطية، رؤية/تغيير أسرار التكوين، رؤية معلومات التعريف الشخصية للأشخاص، الوصول إلى الرسائل الشخصية، …) ومن الأفضل إبقاء هذه الدائرة ضيقة.

هناك مجال كبير لـ “الامتيازات العالية” دون أن يكونوا مسؤولين كاملين.

شكراً لك على هذا التوضيح، لم أكن أعلم أن هذا هو الحال. أنت على حق، سنحد من ذلك بالتأكيد الآن بعد أن علمت.

@supermathie

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

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

أكبر مخالف هو حدود مشاهدات الصفحة. 50 ألف مشاهدة صفحة شهريًا هي بالتأكيد أكثر من كافية لمعظم مشاريع البرمجيات الحرة والمفتوحة المصدر، لكننا نولد حركة مرور أكبر بكثير من ذلك. لقد تلقى موقعنا الرئيسي 1.87 مليون طلب إجمالي من 56.47 ألف زائر فريد خلال الأيام السبعة الماضية وحدها. أخشى أن نصل بسهولة إلى حد مشاهدات الصفحة بهذا المعدل.

شكراً لك على لفت انتباهي إلى هذا الأمر!

[simon]

@jonbarrow

لا يوجد ضمان بأن يكون لدى الموظفين رسائل بريد إلكتروني فريدة أيضًا، لذا لن أرغب في الاعتماد عليها.

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

هناك عدد قليل من الحالات التي يكون فيها تمكين الموظفين من تلقي رسائل البريد الإلكتروني من Discourse مفيدًا. الحالة الأولى التي من المحتمل أن تواجهها هي أن Discourse يوفر مسار /u/admin-login للموظفين. يعرض هذا المسار نموذجًا يقبل عنوان بريد إلكتروني للموظفين. سيرسل Discourse رابط تسجيل دخول يستخدم مرة واحدة إلى عضو الموظفين. إنه مفيد لإعداد SSO - إذا قمت بقفل نفسك عن طريق الخطأ من الموقع عند إعداده، فسيسمح لك بالعودة إليه. كما أنه مفيد إذا كانت هناك مشكلة في خادم المصادقة الخاص بك.

[jonbarrow (Jonathan Barrow)]

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

ومع ذلك، الآن بعد أن أصبح من الواضح أن DiscourseConnect يستخدم أولاً المعرف الفريد للبحث عن المستخدمين وأن الجزء “يستخدم ديسكورس رسائل البريد الإلكتروني لربط المستخدمين الخارجيين بمستخدمي ديسكورس” من منشور DiscourseConnect يشير فقط إلى ربط مستخدمي SSO الجدد بحسابات ديسكورس الحالية، وتم توضيح سوء فهمي لكيفية عمل موجه تسجيل الدخول، هل هناك أي شيء يمنعنا فعليًا من إرسال عناوين بريد إلكتروني مكررة كما هي؟ أم أن هذا التفرد مفروض بشكل صارم؟

[simon]

@jonbarrow

هل هناك ما يمنعنا فعليًا من إرسال عناوين بريد إلكتروني مكررة كما هي؟

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

ستحتاج إلى التأكد من أن رسائل البريد الإلكتروني المرسلة في الحمولة فريدة لكل مستخدم.

[jonbarrow (Jonathan Barrow)]

حسنًا، شكرًا على هذا التوضيح هل من الممكن تحديث البريد الإلكتروني للمستخدم يدويًا في وقت لاحق؟ الآن بعد حل مشكلة موجه تسجيل الدخول، قد أفكر في تنفيذ الفكرة التي كان لدى فريقي قبل ذلك، باستخدام رسائل بريد إلكتروني وهمية وخادم SMTP نقوم بتشغيله يقوم بتعيين رسائل البريد الإلكتروني الوهمية هذه إلى البريد الإلكتروني الحقيقي للمستخدم. على سبيل المثال، سنقوم بتحديث جميع رسائل البريد الإلكتروني لـ Discourse إلى شيء مثل userid@example.com، والذي يتصل بخادم SMTP الخاص بنا أولاً ويأخذ userid للبحث عن البريد الإلكتروني الحقيقي للمستخدم. ومع ذلك، لن يكون هذا شيئًا جاهزًا لدينا في وقت قريب، لذلك سنحتاج إلى تحديث رسائل البريد الإلكتروني لـ Discourse للمستخدمين لاحقًا إذا كان ذلك ممكنًا.

[simon]

@jonbarrow

هل من الممكن تحديث البريد الإلكتروني للمستخدم يدويًا في وقت لاحق؟

نعم. ستحتاج إلى تمكين إعداد الموقع auth overrides email لهذا الغرض. عند تمكينه، تتم مزامنة البريد الإلكتروني لمستخدم Discourse مع البريد الإلكتروني المضمن في حمولة المصادقة (حمولة DiscourseConnect في حالتك) في كل مرة يقوم فيها المستخدم بتسجيل الدخول. إذا لم يكن ممكّنًا، فسيتم تعيين البريد الإلكتروني للمستخدم إلى البريد الإلكتروني في حمولة المصادقة عند إنشاء الحساب الأولي، ولكن لن يتم تحديثه في عمليات تسجيل الدخول اللاحقة.

بافتراض تمكين auth overrides email، يمكنك أيضًا تحديثه دون مطالبة المستخدمين بتسجيل الدخول عن طريق إجراء طلب API إلى المسار sync_sso: مزامنة بيانات مستخدم DiscourseConnect مع المسار sync_sso.

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

@jonbarrow

على سبيل المثال، سنقوم بتحديث جميع رسائل البريد الإلكتروني في Discourse إلى شيء مثل userid@example.com، والذي يتصل بخادم SMTP الخاص بنا أولاً ويأخذ userid للبحث عن البريد الإلكتروني الحقيقي للمستخدم. هذا ليس شيئًا سنكون جاهزين له في وقت ما، لذلك سنحتاج إلى تحديث رسائل البريد الإلكتروني في Discourse للمستخدمين لاحقًا إذا أمكن.

ربما يمكنك فقط تعيين رسائل البريد الإلكتروني إلى شيء ذي معنى في البداية. بمجرد إعداد موقع Discourse، يجب عليك إجراء بعض الاختبارات لمعرفة نطاقات البريد الإلكتروني التي سيقبلها Discourse للرسائل الإلكترونية المزيفة. بالاعتماد على الذاكرة، أعتقد أن @invalid.com مقبول. لست متأكدًا من النطاقات الأخرى. من جانبك، يمكنك تعيين شيء مثل <userId>@invalid.com إلى عنوان البريد الإلكتروني الفعلي للمستخدم.

[jonbarrow (Jonathan Barrow)]

لقد كنت مفيدًا للغاية، شكرًا جزيلاً لك! حل واجهة برمجة التطبيقات (API) هو ما كان يدور في ذهني، ولكن معرفة أنه يمكنه المزامنة بنفسه يعمل بشكل مثالي أيضًا.

@simon

ربما يمكنك ببساطة تعيين رسائل البريد الإلكتروني إلى شيء ذي معنى في البداية

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

[jonbarrow (Jonathan Barrow)]

@simon @supermathie لقد كنتم متعاونين للغاية حتى الآن، وآمل أن أتمكن من الخروج قليلاً عن نطاق هذا الموضوع وطلب بعض المساعدة الإضافية؟

لقد قمت بتثبيت Discourse على جهاز محلي للاختبار، باستخدام Install Discourse for development using Docker كدليل لي. لم أتمكن من العثور على أي أدلة أخرى حول كيفية إعداده للاختبار المحلي؟ يبدو أن الويكي يغطي فقط إعدادات الإنتاج، والتي تتطلب إعداد النطاق/DNS/SMTP الخاص بك بالفعل. لم نكن نرغب في عرض المنتدى للجمهور حتى يتم تنفيذ كل شيء من جانبنا، لذلك احتجنا إلى اختبار محلي حيث لم يكن أي من هذا مطلوبًا.

لقد قمت بتشغيله باستخدام هذا الدليل، وقمت بتطبيق SSO على نسخة محلية من موقعنا، ولكنني واجهت مشكلتين حتى الآن:

1. يبدو أن إعادة التوجيه إلى return_sso_url تعمل جزئيًا فقط؟ في حالتي، عنوان URL هو http://localhost:3000/session/sso_login. إنه يعيد التوجيه بنجاح، ولكن بعد إعادة التوجيه الأولية، يرسلني إلى http://localhost:3000، والذي يعرض فقط الخطأ RuntimeError: Discourse does not support compiling scss/sass files via Sprockets. الخيط الوحيد الذي تمكنت من العثور عليه حول هذا الخطأ هو https://meta.discourse.org/t/error-when-building-discourse-does-not-support-compiling-scss-sass-files-via-sprockets/305402، ولكن لم يبدو أن ذلك قد تقدم حقًا. لم يقبل OP أي حل، والشيء الوحيد الذي حدث هو السؤال عن أحجام ذاكرة الوصول العشوائي والمبادلة (الجهاز الذي يعمل عليه هذا لديه 32 جيجابايت من ذاكرة الوصول العشوائي و 2 جيجابايت مبادلة. لذلك أشك في أن هذه هي المشكلة؟)
2. يبدو أن avatar_force_update لا يتم احترامه؟ أو على الأقل، ليس للمستخدمين المسؤولين؟ لقد قمت بتمكين discourse connect overrides avatar في إعدادات الموقع، وفي حمولة استجابة SSO أقوم بتعيين كل من avatar_url و avatar_force_update. ولكن عند تسجيل الدخول إلى حساب المسؤول (الذي يرتبط بحسابي الخارجي) فإنه لا يعرض صورتي الشخصية الخارجية؟ يمكنني رؤية أن external_avatar_url يتم تعيينه بشكل صحيح عند التحقق من بيانات المستخدم المسؤول عبر واجهة برمجة التطبيقات، ولكنه لا يبدو أنه يتم استخدامه في واجهة المستخدم؟

[simon]

@jonbarrow

لقد قمت بتثبيت Discourse على جهاز محلي للاختبار، باستخدام تثبيت Discourse للتطوير باستخدام Docker كدليلي. لم أتمكن من العثور على أي أدلة أخرى حول كيفية إعداده للاختبار المحلي؟

هناك قائمة بطرق التثبيت هنا: Set up a local Discourse Development Environment?. لدي موقع تطوير غير Docker (باستخدام دليل Ubuntu). إذا كان بإمكانك القيام بذلك، أعتقد أنك ستحصل على أفضل النتائج من النهج غير Docker. أحد الأسباب التي تجعلني أستخدمه هو عدم الاضطرار إلى التعامل مع مشاكل الشبكة لطلبات API بين Discourse والتطبيقات الأخرى التي أقوم بتطويرها محليًا. إنه أسرع من Docker أيضًا.

@jonbarrow

يبدو أن avatar_force_update لا يتم احترامه؟ أو على الأقل، ليس للمستخدمين الإداريين؟

يجب أن يكون كذلك. تأكد من أن التطبيق الذي تقوم بإنشاء حمولة SSO عليه لا يقوم بتحويل القيمة المنطقية true إلى 1. هذه مشكلة شائعة. للتغلب على ذلك، يمكنك تعيين أي قيم منطقية في حمولة SSO إلى السلاسل النصية "true" أو "false". سيقوم Discourse بتفسيرها بشكل صحيح. تحقق من ذلك أولاً لمعرفة ما إذا كانت هذه هي المشكلة. قد يكون شيئًا آخر. الكود الذي يتعامل مع avatar_force_update معقد نوعًا ما، ولكنه قابل للقراءة: discourse/app/models/discourse_connect.rb at 187204705323b650d61ed25862eb1a0c733aa63c · discourse/discourse · GitHub.

تعديل: بالنسبة لمشكلة القيم المنطقية في حمولة SSO، أعتقد أنه من الأدق القول أنه في عملية إنشاء حمولة SSO، ستقوم البيئة بتحويل القيم المنطقية true/false إلى سلاسل نصية. يتوقع Discourse أن تكون السلاسل النصية "true" أو "false"، وقد تتعامل بيئات البرمجة الأخرى معها بشكل مختلف. على سبيل المثال:

PHP:

wp> strval(true)
=> string(1) "1"

على عكس Ruby:

irb(main):001> true.to_s
=> "true"

Python (لست متأكدًا من كيفية تعامل Discourse مع هذا):

>>> str(True)
'True'

[jonbarrow (Jonathan Barrow)]

@simon

إذا كان ذلك ممكنًا لك، أعتقد أنك ستحصل على أفضل النتائج مع النهج غير الخاص بـ Docker

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

@simon

يجب أن يكون كذلك. تأكد من أن التطبيق الذي تقوم بإنشاء حمولة SSO عليه لا يقوم بتحويل القيمة المنطقية true إلى 1

بالتأكيد لا يتم تعيينه إلى 1. أنا أعمل في JavaScript، والقيمة المنطقية true سيتم تحويلها دائمًا إلى السلسلة النصية \"true\":

String(true); // 'true'

(true).toString(); // 'true'

// هذا ما يستخدمه الكود الخاص بي فعليًا
querystring.stringify({
	avatar_force_update: true
}); // 'avatar_force_update=true'

@simon

الكود الذي يتعامل مع avatar_force_update معقد نوعًا ما، ولكنه قابل للقراءة: discourse/app/models/discourse_connect.rb at 187204705323b650d61ed25862eb1a0c733aa63c · discourse/discourse · GitHub .

لم أعمل مع Ruby من قبل، لذلك لست متأكدًا إلى أي مدى سأصل في التحقق من ذلك فعليًا. ولكن بمجرد إلقاء نظرة سريعة، لا أرى أي مشاكل؟ ومع ذلك، لقد تحققت من أن الإعداد ذي الصلة في لوحة تحكم Discourse وفي حمولة SSO تم تعيينهما:

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

@simon

PHP:

wp> strval(true)
=> string(1) "1"

لأكون منصفًا، في PHP، سترغب دائمًا في استخدام var_export للحصول على التمثيل النصي “الحقيقي” للمتغير، لأنه يُرجع PHP صالحًا لإعادة إنشاء هذا المتغير:

var_export(true); // true

[simon]

ألقِ نظرة على قسم DiscourseConnect الموجود في أسفل صفحة مسؤول المستخدم. يوجد زر يمكنك النقر عليه لتوسيعه لعرض قيم آخر حمولة SSO التي تلقاها Discourse.
يمكنك أيضًا العثور على نفس المعلومات من وحدة تحكم Rails. على سبيل المثال:

>SingleSignOnRecord.last

# أو
>SingleSignOnRecord.where(external_id: 2)

يجب عليك تمكين إعداد الموقع verbose discourse connect logging. يضيف هذا بعض التفاصيل الإضافية إلى السجلات التي يتم إنشاؤها في المسؤول / السجلات / سجلات الأخطاء. بالنسبة لمشكلة الصورة الرمزية، من الممكن أن تظهر إدخالات السجل ذات الصلة كسجلات أخطاء عادية، وليس سجلات DiscourseConnect.

@jonbarrow

بصراحة، في PHP، سترغب دائمًا في استخدام var_export للحصول على التمثيل “الحقيقي” للسلسلة النصية للمتغير،

من المحتمل أن تكون المشكلة خاصة بـ WordPress. تعيد دائمًا 1 للقيمة true و "1" للتمثيل النصي للقيمة true.

[jonbarrow (Jonathan Barrow)]

@simon

ألقِ نظرة على قسم DiscourseConnect الموجود في أسفل صفحة مسؤول المستخدم. يوجد زر يمكنك النقر عليه لتوسيعه لعرض قيم آخر حمولة SSO استقبلتها Discourse.

إنها الحمولة المتوقعة، ويتم عرض رابط صورة الملف الشخصي بشكل صحيح:

يجب أن تكون صورة الملف الشخصي هذه:

ولكنها لا تزال تظهر كـ:

وهو الـ Gravatar الخاص بي:

ما لم أكن أسيء فهم هذا الإعداد، أو ما لم يكن هناك شيء آخر أحتاج أيضًا إلى تعيينه، فقد قمت بتمكين الإعداد لتجاوز هذه:

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

[simon]

هل هذا على موقع التطوير المحلي الخاص بك؟

أتساءل عما إذا كان تحميل الصورة الرمزية قد فشل لسبب ما. حاول تمكين إعداد الموقع verbose discourse connect logging، ثم قم بتسجيل الخروج وتسجيل الدخول مرة أخرى. يجب أن يكون هناك رسالة واحدة على الأقل في السجلات تتعلق بالصورة الرمزية:

app/models/user_avatar.rb

ربما سيكون هناك خطأ آخر يتعلق بفشل التحميل.

[supermathie (Michael Brown)]

@jonbarrow

RuntimeError: Discourse لا يدعم تجميع ملفات scss/sass عبر Sprockets

في حال لم تكن قد اكتشفت ذلك بالفعل، فهذا يعني: “يجب عليك الوصول عبر وكيل ember-cli بدلاً من المتصفح مباشرة”.

استخدم bin/ember-cli -u لتشغيله للتطوير.

لقد قمت بمضاعفة وضع الصورة الرمزية الخاص بك:

قبل:

حمولة تسجيل الدخول:

بعد:

لكن:

أعتقد أن هذا خطأ حيث يقوم Discourse بتعيين عنوان URL المخصص للصورة الرمزية بشكل صحيح ولكنه لا ينتقل من Gravatar إلى الصورة المخصصة.

إذا قمت بإنشاء مستخدم جديد:

فإنه يعمل على الفور:

لذا أشك في أن هذا يتم تشغيله عن طريق وجود حساب تم تعيين Gravatar له قبل استخدام DiscourseConnect.

[jonbarrow (Jonathan Barrow)]

@simon

إذا كان ذلك ممكنًا بالنسبة لك، أعتقد أنك ستحصل على أفضل النتائج من النهج غير المتعلق بـ Docker

تمكنت من جعل خطوات Ubuntu تعمل (بعد الكثير من التعديلات، حيث كان برنامج تثبيت البرنامج النصي يتعارض مع الحزم والبرامج المثبتة لدي بالفعل). هذا أصلح الخطأ الأصلي الذي كان لدي، لكن تسجيل الدخول الموحد لا يزال يعمل جزئيًا فقط. الآن بدلاً من خطأ scss/sass، يعطي تسجيل الدخول الموحد انتهت مهلة تسجيل دخول الحساب، يرجى المحاولة مرة أخرى لتسجيل الدخول. في كل مرة. النقر على زر تسجيل الدخول للمرة الثانية أثناء التواجد على صفحة الخطأ هذه يكمل تسجيل الدخول، مع ذلك. لم تحدث أي تغييرات في التعليمات البرمجية من جهتي، فقط الطريقة التي يعمل بها Discourse.

سأعتبر كل هذا مجرد غرائب تشغيل هذا محليًا. آمل ألا تواجه عمليات النشر الإنتاجية نفس المشكلات.

@supermathie

في حال لم تكن قد اكتشفت ذلك بالفعل، فهذا يعني: “يجب عليك الوصول عبر وكيل ember-cli بدلاً من المتصفح مباشرة”.

استخدم bin/ember-cli -u لتشغيله للتطوير.

لم يبدو أن هذا يفعل أي شيء مع إصدار Docker. سينتهي البرنامج النصي بدون إخراج، ولم يحدث شيء فعليًا في جانب Discourse. هذا يتعارض أيضًا مع الخطوات المدرجة في دليل Docker، وهو أمر غريب. هل هناك سبب لعدم ذكر ذلك هناك؟

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

@supermathie

لقد قمت بتكرار وضع الصورة الرمزية الخاص بك

يسعدني سماع أنني لست الوحيد! الأخطاء ليست ممتعة أبدًا ولكني سعيد بالمساعدة في العثور على هذا الخطأ.

[simon]

@jonbarrow

سأعتبر كل هذا مجرد غرائب في تشغيله محليًا. آمل ألا تواجه عملية النشر الإنتاجية نفس هذه المشكلات.

قد يكون هذا هو الحال، ولكن يجب أن تكون قادرًا على تشغيل DiscourseConnect محليًا دون أي مشكلات. هل تصل إلى Discourse على http://localhost:4200؟ هناك مشكلة غريبة (في رأيي) حيث يمكن الوصول إلى Discourse إما على localhost:4200 أو 127.0.0.1:4200 في بيئة تطوير محلية. سألتزم بنطاق localhost. يتم التعامل معه كجلسة مختلفة عن 127.0.0.1.

على أي حال، هذا مجرد تخمين حول ما يحدث. تأكد من تمكين إعداد تسجيل الأخطاء التفصيلي وانظر إلى السجلات للحصول على التفاصيل.

@jonbarrow

كان نص التثبيت يتعارض مع الحزم والبرامج التي قمت بتثبيتها بالفعل)

يجب أن توضح تعليمات التثبيت أنك لست بحاجة إلى تشغيل النص البرمجي. يمكنك ببساطة المرور عبر النص البرمجي خطوة بخطوة للتأكد من تثبيت جميع التبعيات.

[jonbarrow (Jonathan Barrow)]

@simon

هل تصل إلى Discourse على http://localhost:4200؟

نعم أفعل.

@simon

يجب أن توضح تعليمات التثبيت أنك لست بحاجة إلى تشغيل البرنامج النصي.

التي تم ربطها سابقًا لا توضح ذلك. ذهبت إلى https://meta.discourse.org/t/set-up-a-local-discourse-development-environment/182882، واخترت Install Discourse on Ubuntu or Debian for Development لأنني أستخدم Ubuntu 22.04.3. تقول هذه الصفحة أنه لا يتعين عليك تشغيل البرنامج النصي بأكمله، ولكن فقط بنص صغير بعد الجزء الذي يوجه المستخدمين لتشغيله.

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

وضع هذا الإخلاء بعد التعليمات بالتأكيد لا يجعلها واضحة، في رأيي.

[jonbarrow (Jonathan Barrow)]

@simon

تأكد من تمكين إعداد التسجيل المطول وانظر إلى السجلات للحصول على التفاصيل.

يبدو أنه يعتقد أن الرقم العشوائي غير صحيح؟ أرى هذا في السجلات الآن عند تسجيل الدخول:

لا يمكن التحقق من صحة رمز CSRF. 3:44 مساءً
سجل SSO المطول: بدأت عملية SSO add_groups: admin: avatar_force_update: avatar_url: bio: card_background_url: confirmed_2fa: email: external_id: failed: groups: locale: locale_force_ 3:44 مساءً
سجل SSO المطول: الرقم العشوائي غير صحيح، تم إنشاؤه في جلسة متصفح مختلفة، أو انتهت صلاحيته add_groups: admin: avatar_force_update: true avatar_url: https://pretendo-cdn.b-cdn.net/mii/1424784 3:44 مساءً
سجل SSO المطول: بدأت عملية SSO add_groups: admin: avatar_force_update: avatar_url: bio: card_background_url: confirmed_2fa: email: external_id: failed: groups: locale: locale_force_ 3:44 مساءً
سجل SSO المطول: تم تسجيل دخول المستخدم على PN_Jon add_groups: admin: avatar_force_update: true avatar_url: https://pretendo-cdn.b-cdn.net/mii/1424784406/normal_face.png bio: card_background_url: confirm 3:44 مساءً
لم يتم العثور على MaxMindDB (/home/jon/discourse/vendor/data/GeoLite2-City.mmdb): لا يوجد مثل هذا الملف أو الدليل @ rb_sysopen - /home/jon/discourse/vendor/data/GeoLite2-City.mmdb 3:44 مساءً
لم يتم العثور على MaxMindDB (/home/jon/discourse/vendor/data/GeoLite2-ASN.mmdb): لا يوجد مثل هذا الملف أو الدليل @ rb_sysopen - /home/jon/discourse/vendor/data/GeoLite2-ASN.mmdb 3:44 مساءً

بعد مزيد من الفحص، يبدو أن السبب هو أن إعادة توجيه SSO لا تستخدم localhost. إنها تعيدني إلى 127.0.0.1. إذا قمت بالتبديل من استخدام localhost إلى استخدام 127.0.0.1 في البداية، يتم إصلاح المشكلة.