آمل أن يتمكن أحد من تقديم بعض النصائح، وسأكون مدينًا لكم بذلك. سأشرح الوضع.
لقد قمت بإعداد Discourse عدة مرات على نطاقي الخاص، hostballs[.]com. في كل مرة، يتم إعادة توجيه www[.]hostballs[.]com بشكل جميل إلى hostballs[.]com، لأن شهادة LetsEncrypt تغطي كلا النسختين مع وبدون www. هذا هو السلوك الافتراضي والمعروف لديسكورش مع تطبيقه لـ LE.
حاليًا، يقوم تثبيت Discourse الجديد بإعداد SSL للموقع غير المرفق بـ www (كما هو مُعدّ في عنوان URL)، لكنه لا يغطي www. هذا يعني أن أي شخص يزور www[.]hostballs[.]com لن يتم إعادة توجيهه، بل سيواجه خطأً في SSL. وبما أنني أعرف أن السلوك الافتراضي يختلف عن هذا، وأن تثبيت Discourse مُتحكَّم فيه للغاية لدرجة أنني لا أرغب في اللجوء إلى certbot والبدء في القيام بكل شيء يدويًا (أليس هذا سيجعل التحديثات الدورية ممتعة؟)، فأنا غير متأكد من أفضل مسار للمضي قدمًا.
بينما كنت أحاول حل هذه المشكلة، قمت بتعليق قوالب ssl و LE، بالإضافة إلى عنوان البريد الإلكتروني لـ LE، في ملف app.yml. ثم قمت بحذف مجلدي letsencrypt و ssl من /shared/standalone. أعيد بناء الموقع بدون SSL، ثم أعدت تمكين هذه الخيارات في app.yml وأعدت البناء مرة أخرى لتوليد شهادات وتكوينات SSL جديدة. وعلى الرغم من نجاح ذلك، إلا أنه لم يحل مشكلة www.
إذا كانت النصيحة أعلاه تبدو مخيفة للغاية، فيمكنك أيضًا إعداد إعادة توجيه DNS بسيطة. معظم مسجلي النطاقات يقدمون هذه الخدمة.
لا يمكن نشر Discourse تحت عناوين URL متعددة؛ فالتسجيل الجذري (بدون www) وسجل ‘A’ الخاص بـ www هما عنوانان منفصلان. بمجرد تحديد اسم نطاق كامل (FQDN) لموقعك، يجب التعامل مع أي عناوين إضافية عبر إعادة توجيه.
شكرًا لكم يا أصدقاء. دعوني أتطرق إلى بعض التفاصيل التي قد تساعد شخصًا آخر في المستقبل.
بدأت هذه القصة عندما أخبرني مستخدم أن زيارة www لم تعمل، بل أظهرت خطأ في الشهادة. وعند زيارة رابط https المباشر الذي قدمه في موضوع الإبلاغ، واجهت نفس المشكلة. في الماضي، عند استخدام www، لم أواجه هذه المشكلة، بل كنت أحول تلقائيًا إلى النطاق الجذري دون أي عوائق. هذا قادني إلى الاستنتاج بأن تثبيتاتي بعد الهجرة الأخيرة كانت معطلة بطريقة ما ولا تتصرف وفقًا للخصائص الافتراضية لتثبيت جديد لـ Discourse.
لذلك، قمت بتثبيت نسخة جديدة من Discourse على نطاق جديد لإثبات أن www تعمل افتراضيًا عند استخدام النطاق الجذري. ذهبت إلى النطاق، ثم قمت بتعديل الرابط في شريط العناوين وأضفت “www.” في البداية. تم التحويل إلى النطاق الجذري دون أي مشكلة، كما توقعت. ثم فكرت في تجربة شيء آخر. قمت بكتابة “https://” يدويًا قبله. عندها فشلت العملية مع نفس خطأ الشهادة.
إذن، ما قد يكون قادني إلى افتراض أن التوقيع لـ www هو السلوك الافتراضي في تطبيق LE الخاص بـ Discourse قد يكون في الواقع ناتجًا عن متصفحي الذي يحدد المنفذ 80 افتراضيًا بينما يخفي جزء http/https من الرابط أثناء إعادة كتابة الرابط في شريط العناوين.
أسهل حل لمن يستخدمون نطاقهم الجذري ويريدون أن يكون www موقّعًا من Let’s Encrypt لتحويل HTTPS الصحيح دون تعقيد الأمور أو استخدام خادم ويب آخر لإدارة التحويل:
أجل، لا أرى طريقة لتحقيق ذلك دون أن تكون عرضة للكسر عند التحديثات. يبدو أن هذه هي المعضلة التي يواجهها الأشخاص المخصصون لنطاقات خاصة للمجتمعات ولا يحبون النطاقات الفرعية غير الضرورية.
إلا إذا كنت ستشغل خادم ويب آخر في مكان آخر، بالطبع.