لقد قمت بإعداد خوادم Discourse في حوالي 5 حالات، وجميعها تظهر سلوكًا غريبًا؛ لست متأكدًا مما إذا كان هذا عيبًا فعليًا أم أن أي شخص آخر واجه نفس المشكلة.
خطوات إعادة الإنتاج
إعداد الخادم يسير بسلاسة
تمرير المعالج يسير بشكل جيد، ويتم تحميل جميع الصور وعرضها كما هو متوقع
يتلقى المستخدم رابط التسجيل، ينقر عليه للمتابعة، ويتم التسجيل بنجاح
(هنا تبدأ الأمور في الانحراف) يسجل المستخدم الدخول وتظهر شعارات الموقع مكسورة — تظهر فقط عناوين النصوص
لا يمكن للمستخدم رفع/تعيين صورة شخصية مخصصة
يشكو شهادة الموقع من أن الموقع غير آمن
لسبب ما، هذا يؤثر فقط على المتصفح المستخدم للتسجيل، ومعدل الفشل أعلى بكثير في Chrome
استكشاف الأخطاء وإصلاحها
حاولنا إخبار المستخدمين بتفريغ ذاكرة التخزين المؤقت للمتصفح وملفات تعريف الارتباط — لا يزال الأمر معطلاً
طلبنا من المستخدمين إعادة تثبيت المتصفحات، معظمها Chrome — لا يزال الأمر معطلاً
طلبنا من الناس استخدام هوية بديلة في Chrome أو تجربة متصفح آخر (Safari، Firefox، إلخ) — يعمل!
ليس لدينا أي فكرة على الإطلاق عن سبب عمل العنصر الأخير ولماذا هوية التسجيل الأصلية معطلة. لن يكون من المقبول السماح لمستخدمينا (حوالي 600-700 مستخدم) بتسجيل الخروج من هوية Chrome الخاصة بهم ثم تسجيل الدخول مرة أخرى — إذا كان هذا هو الحل بالفعل.
إذا كان Discourse خلف وكيل عكسي مُهيأ بشكل صحيح، فإن force_https ستحدث فرقًا بالتأكيد. الإعداد يخبر Discourse بشكل أساسي بتحميل جميع الموارد والأصول عبر HTTPS.
لقد حدث ذلك، بالمناسبة. أغلقني خارج النظام. تفعيل force_https حل مشكلة الصور، لكنه جعل من المستحيل المصادقة من المتصفحات بجلسة جديدة. الجلسة الحالية تعمل بشكل جيد، لكن بمجرد تسجيل الخروج، لا يمكنك العودة مرة أخرى.
لقد فعلت ذلك للتو، فقد قمت بالفعل بإعداد كل شيء في كتلة الخادم الخاصة بي بالطريقة التي يقترحها المقال. وهذا على الأرجح هو السبب في أن الجلسات في الملفات الشخصية البديلة/المتصفحات تعمل بشكل طبيعي بعد التسجيل/المصادقة الأولية.
العنصر الوحيد الذي يختلف فيه تكويني هو أنني لا أستخدم templates.yml.
سيستغرق هذا الأمر قدرًا كبيرًا جدًا من التحقيق الإضافي.