نقل الموقع خلف وكيل، والأيقونة والرأس لم يعد يستخدمان HTTPS

لقد نقلتُ مثيل Discourse الخاص بي بين الخوادم منذ ذلك الحين، وهو الآن يعمل خلف وكيل عكسي مع إنهاء SSL.

ومع ذلك، لا يتم طلب صورة الرأس وأيقونة الموقع عبر HTTPS ويتم حظرها. لقد حاولت ضبط “فرض https” على التشغيل، لكن هذا لم يساعد.

image

هل يقوم الوكيل الخاص بك بتزويد رأس X-Forwarded-Proto؟ (يجب أن يفعل ذلك).

هل يقوم الوكيل الخاص بك بتزويد رأس X-Forwarded-Proto؟ (يجب أن يفعل ذلك).

نعم، يفعل ذلك.

واجهتُ نفس المشكلة. لديّ نسخة من Discourse خلف HAProxy مع إنهاء SSL. الإصلاح بسيط جدًا، لكنه غير واضح:

  1. أولاً، تأكد من تفعيل خيار “فرض HTTPS” في الإعدادات (انتقل إلى الإعدادات ثم قم بالبحث عن “فرض HTTPS”).
  2. انتقل إلى الإعدادات > الهوية البصرية > ثم أعد رفع الشعارات الخاصة بك.
  3. يجب أن يستخدم كل شيء HTTPS الآن (تأكد من تحديث الصفحة في المتصفح).

(أعتقد أن هذا قد يكون خطأً في Discourse)

مرحبًا،
أود العودة إلى هذه المسألة. في الواقع، أعاني من نفس المشكلة، ولا يمكنني تفعيل خيار force_https على قيمة true لأنه لا توجد طريقة لتسجيل الدخول (خطأ غير معروف عند تسجيل الدخول).
كيف يمكننا إجبار الشعار على التحميل عبر طلب HTTPS بدلاً من HTTP؟
أليس من المفترض أن يكون ذلك سهلاً؟
شكرًا جزيلًا لكم على ردكم (لقد قضيت ساعات طويلة جدًا من جهدي لحل هذه المشكلة).

ستحتاج إلى عكس إعداد الموقع force_https عبر الاتصال بالسيرفر باستخدام SSH وإدخال سطر الأوامر Ruby. توجد مواضيع howto حول كيفية القيام بذلك هنا.

شكرًا لك على ردك. لقد كنت بالتأكيد غير واضح في رسالتي. في الواقع، أستطيع تغيير إعداد force_https باستخدام أمر Rails دون أي مشكلة. لذا، ولأكون أكثر وضوحًا:

إلى أن قمت بآخر ترقية قبل بضعة أيام، والتي تطلبت إعادة بناء حاوية Docker، كان لدي حل كامل يعمل مع إعداد force_https مضبوط على true، وكان علي تطبيق التصحيح التالي في قسم server في ملف إعدادات nginx للحصول على تسجيل دخول صالح:

  if ($http_x_forwarded_proto = 'http'){
    return 301 https://$host$request_uri;
  }

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

حصلت على المسار التالي من سجل الإنتاج:

 Started POST "/session" for 193.134.222.4 at 2020-05-14 19:24:40 +0000
 Processing by SessionController#create as */*
 Parameters: {"login"=>"rossierd", "password"=>"[FILTERED]", "second_factor_method"=>"1", "timezone"=>"Europe/Zurich"}
 Can't verify CSRF token authenticity.
 Rendering text template
 Rendered text template (Duration: 0.0ms | Allocations: 1)
 Filter chain halted as :verify_authenticity_token rendered or redirected
 Completed 403 Forbidden in 2ms (Views: 0.7ms | ActiveRecord: 0.0ms | Allocations: 1101)

بما أن حاوية Discourse الخاصة بنا تعمل على آلة افتراضية (VM) ويمكن الوصول إليها عبر https.

هل لديك أي فكرة عن سبب هذا التغير في السلوك قبل وبعد الترقية؟

حتى الآن، قمت بتعطيل force_https وضبطه على false، وجميع الأشياء تعمل بشكل جيد باستثناء الشعار الموجود في الزاوية العلوية اليسرى (شعار العلامة التجارية) الذي لا يظهر بشكل صحيح لأنه يُشار إليه باستخدام طلب http://…

بالمناسبة، إليك عنوان موقعنا: https://discourse.heig-vd.ch

بالإضافة إلى ذلك، وجدت إعداد الموقع التالي الذي يحتوي على عنوان URL المذنب:
SiteSetting.site_favicon_url (وهو الآخر هو SiteSetting.site_apple_touch_icon) مع “http://…jpeg”.
ومع ذلك، لا يبدو من الواضح تغيير القيمة بأمر سكة حديد بسيط كما نفعل مع force_https على سبيل المثال)…

هل يمكنكم المساعدة في هذا الموضوع من فضلكم؟

تمت إعداد هذه الإعدادات عبر معالج الإعداد. قم بتشغيل معالج الإعداد مرة أخرى وأعد تحميل الصور.

ضبطت الصور بهذه الطريقة. أعدت تشغيل المعالج، لكن النتيجة النهائية كانت نفسها :disappointed_face:
أعتقد أن رفع الصور لا يؤثر على طريقة الإشارة إليها؛ بل إنها مسألة تتعلق بتوليد صفحة الويب.

حسنًا، بعد العديد من المحاولات الفاشلة، تمكنت أخيرًا من فهم كيفية تسجيل الدخول بشكل صحيح مع force_https=true.

في بيئة Docker، قمت بتعديل ملف /etc/nginx/conf.d/discourse.conf على النحو التالي:


location @discourse {
limit_conn connperip 20;
limit_req zone=flood burst=12 nodelay;
limit_req zone=bot burst=100 nodelay;
proxy_set_header Host $http_host;
proxy_set_header X-Request-Start “t=${msec}”;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https; # $thescheme; ← ما قمت بتعديله
proxy_pass http://discourse;
}

وهو يعمل فقط في هذا القسم، على الأقل في بيئتي.

يعمل الآن بشكل ممتاز!