DiscourseConnect يولد إعادة توجيه HTTP حتى مع تفعيل force_https

تثبيت
1

أنا أقوم بتشغيل Discourse خلف Traefik في إعداد مخصص - إعطاء Discourse جهازًا افتراضيًا خاصًا به ليس خيارًا هنا.

لا يحتوي Discourse الخاص بي على قوالب SSL/Let’s Encrypt ممكّنة، حيث أن Traefik لا يسمح لطلبات HTTP العادية بالوصول إلى الحاوية - فهو مُعد لإعادة توجيه طلبات HTTP إلى HTTPS.

أواجه مشكلات في إعداد DiscourseConnect، لأنه نظرًا لأن الطلب Traefik -> nginx[Discourse] يتم إرساله عبر نص عادي HTTP (لأن nginx لم يتم إعداد SSL له)، فإن القاعدة في /etc/nginx/conf.d/discourse.conf التي تحاول “الحفاظ على البروتوكول، يجب أن تكون في سياق http” تجعل Discourse (تطبيق Rails) يتلقى طلب HTTP بنص عادي، وبالتالي يعيد توجيه نص عادي HTTP إلى /session/sso - حتى لو كان لدي force_https ممكّنًا.

أعتقد أن هذا هو الخطأ: بغض النظر عن إعدادي، مع تمكين force_https، يجب أن يقوم Discourse دائمًا بإنشاء عناوين URL HTTPS - وهو ما لا يفعله.

أعتقد أن الكود المخالف هو application_controller#redirect_to_login، لكنني لم أتعمق كثيرًا في كود مصدر Discourse لأكون متأكدًا.

هل يمكن حل هذا في الكود نفسه؟

كحل بديل، أحاول إضافة قاعدة لتصحيح discourse.conf الخاص بـ nginx لإزالة تلك القاعدة.

2

يجب أن يكون لدينا بعض الدعم للرؤوس المُعاد توجيهها، ستستخدمها للإشارة إلى NGINX ما هو المصدر

3

هل قمت بتعيين
proxy_set_header X-Forwarded-Proto https;

4

أسهل ما كان بالنسبة لي هو تعيين تسمية إضافية في app.yml الخاص بـ Discourse لإخبار Traefik الخاص بي بإضافة رأس X-Forwarded-Proto: https، ولكن بعد ذلك سيقوم nginx بتجاوز هذا المعامل بنسخته الخاصة.

ويلعب تكوين nginx الخاص بـ Discourse دورًا هنا:

هناك يحاول Discourse تخمين البروتوكول من الطلب الأصلي (والذي، في إعدادي، هو دائمًا نص عادي نظرًا لأن هذا هو ما يرسله Traefik). ثم يستخدم ذلك لـ تعيين X-Forwarded-Proto عدة مرات.

في النهاية، قمت بتحرير containers/app.yml الخاص بي لتثبيت هذه الرؤوس على https:

run:
  - exec: echo "Beginning of custom commands"
  ## If you want to set the 'From' email address for your first registration, uncomment and change:
  ## After getting the first signup email, re-comment the line. It only needs to run once.
  # - exec: rails r "SiteSetting.notification_email='no-reply@forum.cabana.network'"
  - replace:
     filename: "/etc/nginx/conf.d/discourse.conf"
     from: /# attempt to preserve the proto, must be in http context\nmap \$http_x_forwarded_proto \$thescheme {\n  default \$scheme;\n  "~https$" https;\n}/\n
     to: |
       # force https scheme so Discourse generates HTTPs links and redirects (ie, `/login`)
  - replace:
     filename: "/etc/nginx/conf.d/discourse.conf"
     from: "$thescheme"
     global: "true"
     to: "https"
  - exec: echo "End of custom commands"

مرة أخرى، أعتقد أنه إذا كان هناك إعداد force_https، فيجب على تطبيق Discourse-the-rails-app احترامه، بغض النظر عما يتعامل معه الوكيل العكسي أو الأطراف الأخرى أم لا.

5

هذه هي الطريقة التي نفعل بها ذلك على منصة الاستضافة الخاصة بنا؛ لدينا طبقة موازن تحميل تضبط X-Forwarded-Proto لـ nginx+Discourse الذي يستهلكها.

لا نحتاج إلى أي حيل إضافية لجعله يعمل - لست متأكدًا مما يحدث خطأ لديك هنا.

هذا هو بالضبط ما يحدث:

  def self.generate_sso(return_path = "/", secure_session:)
    sso = new(secure_session: secure_session)
    sso.nonce = SecureRandom.hex
    sso.register_nonce(return_path)
    sso.return_sso_url = Discourse.base_url + "/session/sso_login"
    sso
  end

و base_url يأتي من:

  def self.base_protocol
    SiteSetting.force_https? ? "https" : "http"
  end

  def self.base_url_no_prefix
    "#{base_protocol}://#{current_hostname_with_port}"
  end

  def self.base_url
    base_url_no_prefix + base_path
  end
إعجاب واحد (1)