هل سيعمل proxy_set_header X-Forwarded-Proto https; البسيط؟
يأتي طلب http/s من الحاوية إلى خادم IDP لخادم Discourse ID على الإنترنت. لا يوجد مثيل بينهما حيث يمكنني إضافة/تغيير أي رؤوس طلب.
في رأيي، وبافتراض أن “Discourse ID” هو مجرد OAuth قياسي، فإن الطريقة الصحيحة ستكون إما
أ) خيار تكوين لـ Discourse ID حيث يمكنني إضافة نقطة نهاية تكوين “معروفة” تحتوي على جميع قيم تكوين OIDC المطلوبة، بما في ذلك البادئة “https://…”.
ب) نفس الشيء، ولكن مبرمج بالفعل في الكود
ما زلت أحاول فهم التفاصيل الفنية لـ Discourse ID …
يمكنك البحث عن تفاصيل معرف Discourse في الكود الخاص بنا، البروتوكول الذي نستخدمه موجود بالكامل في مستودع Github الخاص بنا. الاختلاف الوحيد مع تطبيقات OAuth الأخرى هو أننا نقوم بتسجيل مثيل تلقائيًا. وأثناء هذا التسجيل التلقائي، نتأكد من أن المثيل الذي يطلب التسجيل هو من يدعي أنه موجود وعلى https (في هذا العصر، لا ينبغي أن يكون أي مثيل Discourse على http://).
تخبرني أخطاء http التي شاركتها أعلاه أن موقعك غير مهيأ بشكل صحيح.
هل يمكنك التحقق من ناتج ما يلي عبر الوحدة الطرفية:
Discourse.base_url
SiteSetting.force_https
إذا حصلت على عنوان URL http:// من الأمر الأول و false من الأمر الثاني، فقد ترغب في تعيين SiteSetting.force_https = true ومعرفة ما إذا كان ذلك سيؤدي إلى إصلاحه. (قد يؤدي ذلك أيضًا إلى تعطيل الأشياء إذا كان التكوين غير صحيح في أماكن أخرى، على الرغم من ذلك. كن حذرًا.)
إعجاب واحد (1)
مرحباً بينار،
ربما يتعين علينا توضيح تفاصيل الإعداد الخاص بي أولاً. إنه مختلف قليلاً مقارنة بالنشر القياسي.
- موازن تحميل مركزي (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.
توماس، آسف، لا يمكنني حقًا مساعدتك في إعداداتك المحددة. كل ما يمكنني قوله هو أن شيئًا ما في مثيلك غير صحيح.
حسنًا، وحدة تحكم JavaScript في موقعك لا تعتقد أن تشفير https خارج الحاوية يغطي كل شيء. تحذيرات JavaScript التي شاركتها أعلاه هي أعراض لمشكلة مماثلة لديك مع معرف الهوية، ويعتقد Discourse نفسه في إعدادك أنه يعمل في http وهذا يمثل مشكلة، لأنه سيقوم بإنشاء عناوين URL في http في بعض الحالات.
إعجابَين (2)
اعتذار كبير جدًا:
لقد قارنت الإعدادات على مثيلنا الإنتاجي (PROD) مع تلك الموجودة على مثيل DEV. كان مثيل DEV فقط هو الذي عطّل إعداد force_https. وقد نجح هذا فقط لأن لدينا مسرّع SSL haproxy SSL أمامه.
لقد قمت الآن بتنشيط SiteSetting.force_http في مثيل DEV ويعمل Discourse ID بشكل جيد. وبالتالي سأقوم أيضًا بنشر Discourse ID على مثيل PROD الخاص بنا (forum.netzwissen.de).
آسف على هذا الالتباس.
3 إعجابات
لا مشكلة، يسعدني أن الأمر قد تم حله. شكراً للمتابعة!
إعجابَين (2)