ولكن هل هذا لا يزال هو الحال؟ إعادة التوجيه لن تساعد في حالتي (وأنا حقًا لا أريد القيام بإعادة كتابة وكيل عكسي متطور لحالة استخدام بسيطة ومؤقتة): في حالتي، أريد تثبيت خادم Discourse جديد بالتوازي مع الخادم الحالي والحصول على عرض مرحلي لهذا الخادم باسم جديد. ومع ذلك، يجب أن يقبل الخادم أيضًا الاسم الرسمي (عندما يحدث التبديل في DNS أو عندما يستخدم المسؤولون اسمًا مستعارًا /etc/hosts). هذا من شأنه أن يحسن مرحلة التدريج بشكل كبير.
أعتقد حاليًا أن المشكلة الرئيسية هي عناوين CSP المطلقة التي تمنع هذا من العمل (على الرغم من أنها تتحقق بالفعل من البروتوكول، يجب أن تكون قادرة على التوسع للتحقق من أسماء المضيفين من قائمة المضيفين المسموح بها). فهل هذا متاح.. في هذه الأثناء؟
بالمناسبة، في حالتي، أختبر باستخدام http، ولكني أعتقد أن إعداد letsencrypt لطلب شهادات متعددة مغطى بالفعل هنا، لذلك سأتمكن من القيام بذلك لاحقًا. (لن يعمل حتى يصبح متاحًا تحت الاسم المستعار الرسمي الصحيح على أي حال)
بالمناسبة، لاحظت للتو أن إعادة بناء حاوية التطبيق باستخدام DISCOURSE_HOSTNAME مختلف لا يعمل - أظن أنه في مكان ما في قاعدة البيانات أيضًا (ولكن لا يمكن تغييره في إعدادات المسؤول).
مما يجعل من المهم إلى حد ما وجود قائمة بالمضيفين المقبولين لمثل هذا السيناريو.
إذا كنت تريد أن تقوم أسماء متعددة بالحل وأن يقوم Discourse بإعادة التوجيه إلى الاسم الصحيح، فأنت جاهز لـ http. بالنسبة لـ https ستحتاج إلى الحصول على شهادة لجميع النطاقات. أعتقد أن إعداد Let’s Encrypt مع نطاقات متعددة يجب أن يساعد.
إذا كنت تريد أن لا يقوم الموقع بإعادة التوجيه إلى نفسه، يمكنك تعديل nginx لعدم القيام بهذا التوجيه. لست متأكدًا من كيفية إخبارك بذلك.
لا تعمل مسألة تغيير اسم المضيف بشكل موثوق بالنسبة لي (على سبيل المثال، على الرغم من إعادة التعيين وإعادة الخبز، فإن رموز تعبيرية تويتر الخاصة بمنشور الترحيب تشير إلى الخادم الخطأ) - لم أبحث في سبب ذلك (سأعلمك). على الأقل ليس الأمر سهلاً.
إعادة التوجيه لحالات الاستخدام الخاصة بي لا تعمل لأنها ستعيد التوجيه إلى الخادم القديم
لا يحتاج تكوين nginx إلى تغيير، فهو غير مدرك لاسم المضيف. لكن المشكلة تتعلق بالتطبيق أكثر، على سبيل المثال، تحتوي رؤوس CSP على عنوان URL الكامل (لا أعرف لماذا).