لدي حاليًا المشكلة التالية وسأكون سعيدًا جدًا إذا تمكن شخص ما من مساعدتي في إيجاد النهج الصحيح.
لقد قمت بتثبيت discourse على خادم Ubuntu 21.10 على Vultr
ذهبت مع الإعداد الافتراضي وقمت بالفعل بإنشاء شهادة Let’s Encrypt (لـ www.example.com) أثناء التثبيت
هدفي هو أن يكون منتدى بلدي متاحًا فقط عبر www → www.example.com وليس example.com
الوضع الحالي:
→ http://example.com يعيد التوجيه بشكل صحيح (301) إلى https://www.example.com
→ http://www.example.com يعيد التوجيه بشكل صحيح (301) إلى https://www.example.com
→ https://example.com يرمي خطأ في الشهادة ولا يتم إعادة توجيهه إلى https://www.example.com الصحيح (تم إصدار الشهادة لـ www.example.com وليس لـ example.com)
ما هو أفضل نهج لجعل https://example.com يعيد التوجيه إلى https://www.example.com وكيف يمكنني تحقيق هدفي؟
ومع ذلك، أعتقد أن هذا لا يزال ليس حلاً مرغوبًا فيه، لأنه يعتمد على خدمة خارجية. بالطبع، إنها مجانية، ولكن ستحتاج إلى إيجاد حل جديد بمجرد تعطل هذه الخدمة.
آمل ألا تفهموني خطأ يا @michaeld، إنه حقًا حل لطيف وسهل تقدمه وأنا أقدره حقًا.
سيكون من الرائع جدًا، إذا كان بإمكانك تحديد أثناء التثبيت القياسي إما استخدام إصدار www أو non www فقط لجعل حياتنا أسهل قليلاً
على الرغم من أنني لم أختبر ذلك في الشهر الماضي، إلا أنني متأكد من أنه يعمل. إذا لم يكن إعداد DNS الخاص بك صحيحًا وقمت بتشغيله عدة مرات، فقد تم تحديد معدلك.
هل تقصد “وطلب شهادة بكلتا الاسمين”؟ هذا صعب للغاية. احتمالية أن يؤدي ذلك إلى كسر الأمور للكثير من الأشخاص الذين لا يعرفون كيفية تكوين DNS بهذه الطريقة مرتفعة جدًا.
إذا قمت بإنشاء شهادة لكل من الإصدار الأساسي وإصدار www، فستكون قد غطيت كليهما. :smiley كما ذكرت، الشهادة لا تتضمن نطاقك الأساسي… وبالتالي الخطأ.
يجب أن تكون عمليات إعادة التوجيه الخاصة بك:
http://example.com → https://example.com
http://www.example.com → https://www.example.com.
ثم أعد توجيه https://example.com → https://www.example.com (النطاق المفضل لديك المذكور).
بعد ذلك، بغض النظر عما إذا كان شخص ما يكتب النطاق الأساسي أو إصدار www، فسوف يصلون إلى https://www.example.com الخاص بك دون أي أخطاء. أفضل ممارسة هي تضمين كل من الإصدار الأساسي وإصدار www في شهادتك. فقط تأكد من أن شهادتك المعدلة/الجديدة هي التي يتم تقديمها بواسطة الخادم الخاص بك، وليس القديمة.
أرى. والآن بعد أن ذكرت ذلك، سأبدأ في التذكر - كان هذا هو السبب الثاني لوضع ديسكورس (Discourse) خلف نجنكس (Nginx) “العادي”. كان السبب الأول هو الحاجة إلى إجراء بعض التصفية. حسنًا، حلي ليس متطورًا أو صعبًا تقنيًا بأي شكل من الأشكال ولكنه ليس شائعًا جدًا في هذه الدائرة.
يجب أن أقول إن دوكر (docker) ليس حلاً سهل الاستخدام إذا كان يجب القيام بشيء بسيط كهذا باستخدام خدمة ويب تابعة لجهة خارجية. بخلاف ذلك، أعتقد أن دوكر (docker) يجب أن يكون مفيدًا جدًا، إلا إذا أصبح شائعًا جدًا.
شكراً على النصيحة @pfaffman . سأحاول مرة أخرى خلال عطلة نهاية الأسبوع.
وبخصوص الموضوع الثاني. أفهم وجهة نظرك، ولكن قد يكون هذا شيئًا مثل إعداد متقدم أو إعداد اختياري، لأنه من المهم حقًا أن يكون المحتوى نفسه قابلاً للوصول عبر نطاق واحد فقط.
في الواقع ليس كذلك (إلا إذا كان Discourse نفسه لا يعمل). ولكن إذا كنت تشير إلى تحسين محركات البحث (SEO) وجوجل، فإن مشكلة النطاق الفرعي هذه لم تكن خطيرة لفترة طويلة. يمكن لجوجل التعامل مع ذلك، لأنه يوجد نطاق واحد فقط - أحدهما هو اسم النطاق المؤهل بالكامل (FQDN) والآخر مع www هو النطاق الحقيقي.