Hello,
I tried using Force https and it seemed to work for me except it was causing login problems. However, the logos are loaded using http by default. They should use the // protocol and let the browser decide which one to use, right? Or maybe there is another solution I’m missing?
Thanks
Hi Eddie,
What version of Discourse are you running? In recent versions logos are uploaded via site settings, instead of being linked using a URL, so this should no longer be an issue.
Hi Joshua, We recently upgraded to v2.2.5. During the previous upgrade, before force https, I believe I deleted the post where the logos were uploaded and switched to the site settings. Everything was fine. Then with v2.2.5, I can’t get rid of the http:// part without force https. I tried reuploading, the wizard, even modifying the images so their hash was different. No luck
Sorry, now I’m confused. Is force_https enabled or not? Is there any possibility you’re overriding the uploaded logos via themes? If your force_https is enabled, and your logos are served via site settings, there should not be a mixed content warning. Are you able to share a link to your site so I can take a look?
It was enabled, thought the upgrade was over. Then our QA reports that logins are not working. so we disabled force https for now. You can test here //forum.y8.com
I checked the themes and didn’t spot anything that might cause this https problem. We mostly use stock, though it is an old stock theme.
With force_https disabled, I can’t test this. We rely on that setting to ensure assets are served over https, not http. Regarding the login issue, it appears you’re using SSO, so ensure the SSO redirect from your provider links to your site via https://, not http://. Once you’ve re-enabled force_https I can take another look.
This forum is using the oauth2 basic plugin. Maybe there is a problem with that, might require a version roll back. Not sure yet. I did check the settings, all addresses were using https, so no obvious problem there.
لدي مشكلة مماثلة هنا:
بعد اكتشاف أن الشعار و الأيقونة الكبيرة يتم تحميلهما عبر HTTP مما يسبب محتوى مختلطًا، فإن تمكين force_https حل هذه المشكلة. لكن تسجيل الدخول لم يعد ممكنًا، مما أدى إلى حلقة إعادة توجيه. بعد تعطيل هذا الخيار، عاد تسجيل الدخول للعمل.
لماذا يحدث هذا؟
ولماذا يتم تحميل هاتين الصورتين فقط عبر HTTP، بينما يتم تحميل جميع الأصول الأخرى بشكل صحيح عبر HTTPS؟
ما هي طريقة تسجيل الدخول الخاصة بك؟ أظن أنها ليست تسجيل الدخول المحلي (اسم المستخدم/كلمة المرور)؟
هل يوجد أي وكيل أو خدمة أخرى أمام تثبيتك؟
أستخدم SSO عبر تطبيق ويب آخر.
يتم استخدام nginx كوسيط عكسي.
كيف تم تكوين nginx؟
يقوم Nginx بإعادة توجيه جميع طلبات HTTP إلى HTTPS، لذا لا ينبغي أن يكون من الممكن تحميل المحتوى عبر HTTP على أي حال.
أول ما يخطر ببالي هو التحقق المزدوج من إعدادات SSO الخاصة بك لمعرفة المكان الذي تحوّل إليه المستخدمين، وكذلك المصادر التي تقبلها. تأكد من أن كل شيء ضمن إعدادات SSO يستخدم https://. كما أنه من الممكن أن تكون هذه مشكلة في Nginx. سيكون من الصعب استكشاف الأخطاء وإصلاحها هنا مع وجود متغيرات متعددة…
أواجه نفس المشكلة تمامًا التي أبلغ عنها الآخرون هنا وفي هذا الموضوع.
المشكلة لا تتعلق بتنفيذ SSO ولا بخادم الويب: في حالتي، يتم إعادة توجيه طلبات HTTP إلى HTTPS، والتي تُمرّر بعد ذلك عبر الوكيل العكسي. يعمل SSO بشكل مثالي إذا قمت بإعادة توجيه المستخدم إلى https://discourse.fqdn.top/session/sso_login?sso=PAYLOAD&sig=SIGNATURE وكانت إعدادات force_https مضبوطة على false. مما يثبت أن كلًا من جزء SSO والوكيل يعملان بشكل مثالي. المشكلة تظهر فقط عندما أحوّل force_https إلى true، عندها يتوقف العمل. عندما يكون لدي جلسة سابقة، يمكنني تغيير force_https إلى true واستخدام Discourse دون أي مشاكل (مما يعزز النقطة القائلة بأن المشكلة لا تتعلق بالوكيل العكسي). ترك force_https مضبوطًا على false ليس خيارًا لأنه يكسر الشعارات، كما أن Chrome غير سعيد عند دمج الأصول من HTTP و HTTPS (يظهر تنبيهًا صغيرًا في شريط العناوين بأن الصفحة غير آمنة).
كيف يبدو ملف إعدادات nginx لديك، وهل يحتوي على رأس X-Forwarded-Proto؟
شكرًا جزيلاً لك. نعم؛ هذا حل المشكلة. إذن كان الأمر يتعلق بالوكيل (proxy). آسف على افتراضي خلاف ذلك، فقط لأن المحتوى تم تحميله.
ولأجل الاكتمال، أنا أستخدم Apache كوكيل عكسي (ReverseProxy) وليس nginx. إليك سطور الإعداد ذات الصلة:
RequestHeader set X-Forwarded-Proto "https"
ProxyPass / http://[::1]:2045/ retry=10
ProxyPassReverse / http://[::1]:2045/
إضافة السطر الأول حلّت المشكلة.
مرحبًا،
آسف لإثارة هذا الأمر مرة أخرى. لكن في الواقع، لا أستطيع التخلص من تحذيرات المحتوى المختلط في متصفح فايرفوكس. المضحك في الأمر أنني أملك إعدادًا مشابهًا جدًا… إلى حد ما. ربما يتمكن أحدكم من تقديم بعض الأفكار أو التحسينات. أنا لست خبيرًا كبيرًا في أوامر Apache، لكن هذا يبدو منطقيًا بالنسبة لي – ولو قليلاً.
لدينا منصة Discourse تعمل داخل Docker خلف خادم Apache عبر وكيل عكسي (Reverse Proxy)، ونُدار شهادات Let’s Encrypt باستخدام ISP Config لأن لدينا العديد من النطاقات “العادية” تعمل على خادمنا.
قمنا بإعداد الوكيل العكسي باستخدام أوامر Apache عبر ISP Config. يبدو إعدادنا كما يلي:
ProxyPreserveHost On
ProxyPass /.well-known/acme-challenge !
RequestHeader set X-Forwarded-Proto "https"
ProxyPass / unix:///var/discourse/shared/standalone/nginx.http.sock|http://localhost/
ProxyPassReverse / unix:///var/discourse/shared/standalone/nginx.http.sock|http://localhost/
RewriteEngine On
RewriteCond %{HTTPS} !on
RewriteRule (.*) https://sub.domain.de$1 [R,L]
لا يزال لدينا تحذيرات محتوى مختلط في فايرفوكس. ما جربته هو تفعيل خيار “فرض SSL” في الإعدادات. كنت النتيجة الأولى أننا لم نتمكن بعد من تسجيل الدخول. نحن نستخدم المصادقة عبر اسم المستخدم وكلمة المرور فقط. لذا جربت الإصلاح المذكور:
حسنًا، أصبح فرض SSL وتسجيل الدخول ممكنًا الآن. لكن لا يزال فايرفوكس يظهر تحذيرات المحتوى المختلط. تقول وحدة التحكم:
و
يتم تسليمهما عبر بروتوكول HTTP… جربنا أيضًا إعادة تحميل صور الهوية البصرية هذه باستخدام sub.domain.de/wizard، لكننا ما زلنا نواجه هذه المشكلة… هل توجد طريقة… لا أعرف… لفرض إعادة تصيير الصور المحسنة باستخدام HTTPS؟ هل هناك خطأ في إعداد الوكيل العكسي لدينا؟
سأكون ممتنًا جدًا لأي مساعدة إضافية هنا. الأمر يشبه محيطًا من تكوينات الوكيل العكسي الممكنة مع فرض SSL عبر Let’s Encrypt (التي تُدار بواسطة) Apache (وليس ضمن إعدادات Discourse المدمجة)، لذا أشعر أنني أغرق. ولدي شعور بأن هناك عددًا قليلًا فقط من الأشخاص يستخدمون Apache كخادم مع وكيل عكسي وتكوين Let’s Encrypt الذي نستخدمه. أو ربما نحن فقط من يخطئ في إعداده.
كما قلت، سأقدّر أي تلميحات. شكرًا مقدّمًا!
جرب SiteIconManager.ensure_optimized! من وحدة تحكم Rails.
واو، إجابة سريعة جدًا! شكرًا جزيلًا.
حسنًا، في الوقت نفسه… لا أعرف ما إذا كان ذلك ناتجًا عن مرور الوقت حتى حدث شيء ما. لكن ما فعلته بعد نشر أول منشور لي هو أنني قمت بتحميل تلك الصور (أيقونة الموقع وأيقونة أبل) مرة أخرى، دون استخدام المعالج، بل عبر إعدادات المسؤول (العلامة التجارية). وفي تلك اللحظة، كنت أريد إغلاق اللسان للتأكد مجددًا من أن تسجيل الدخول وكل شيء يعمل الآن بشكل صحيح… خمن ماذا؟ لقد اختفت أخطاء المحتوى المختلط في فايرفوكس!
واو!
حسنًا، @RGJ، شكرًا لك مرة أخرى كثيرًا، أعتقد أن هذا سيصلح أيضًا إعادة تصيير الصور المحسنة. هل تعتقد أن ذلك حدث في غضون ذلك بسبب عتبة زمنية أم بسبب إعادة تحميل الصور مرة أخرى عبر لوحة المسؤول وليس المعالج؟
شكرًا مرة أخرى، خاصةً @alphanoob1337، على نجاحك أخيرًا في جعل هذا يعمل!
واو، هذا غير مريح جدًا في يوم الاثنين، لكنني غادرت مكتبي بشعور سعيد ومبهج 
