مرحباً بينار،
ربما يتعين علينا توضيح تفاصيل الإعداد الخاص بي أولاً. إنه مختلف قليلاً مقارنة بالنشر القياسي.
- موازن تحميل مركزي (https://www.haproxy.org/) يعمل كمسرع SSL لبعض خدمات الويب المختلفة (ليس فقط لـ Discourse). لا يُسمح بالوصول من الإنترنت إلى أي من هذه الخدمات إلا عبر https. يتم التبديل من http إلى https على موازن التحميل نفسه، انظر Redirect HTTP to HTTPS in a Few Easy Steps with HAProxy كمرجع)
- يقوم haproxy بإعادة توجيه طلبات الواجهة الأمامية إلى الواجهة الخلفية على شبكة خاصة (10.x.x.x) بدون تشفير. ينتهي هذا المرور عند nginx محلي على مضيف docker.
- يقوم nginx بإعادة توجيه الطلبات إلى مقبس http للحاوية web_only باستخدام
proxy_pass ``http://unix``:/mnt/data/discourse/shared/web-only/nginx.http.sock
(أنا أستخدم إعداد حاويتين مع web_only.yml و data.yml). انظر templates/web.socketed.template.yml كمرجع
لا أحتاج إلى SiteSetting.force_https، حيث يتم إجراء جميع تشفير https خارج حاوية Discourse. أنا أستخدم بالفعل OAuth بناءً على المكون الإضافي Discourse OpenID Connect (OIDC) ومع مزود الهوية الخاص بي. يحتوي المكون الإضافي Discourse OIDC على إعداد لـ “المعروف” OpenID Connect discovery document في حالتي: https://login.netzwissen.de/realms/netzwissen/.well-known/openid-configuration
إذا كان Discourse ID سينفذ شيئًا مشابهًا للرابط بين حاوية Discourse ومزود الهوية الخاص بـ Discourse ID، فلن تكون هناك مشاكل. نظرًا لأن “Discourse ID” يستخدم مزود هوية ثابتًا، يمكن حتى ترميز مثل هذا “URL المعروف” بشكل ثابت، بما في ذلك البادئة https.