جعل 'www' يعمل مع Discourse

الدعم
21

لا، لا توجد تثبيت إضافي.

أيضًا، الكتلة الوحيدة التي احتجت إلى إضافتها هي:

  after_ssl:
    - replace:
        filename: "/etc/runit/1.d/letsencrypt"
        from: /--keylength/
        to: "-d mywebsite.org --keylength"

(يبدو أن إعادة التوجيه من http إلى https تعمل بشكل جيد دون كتل replace الإضافيتين، وهاتان اللتان تحتويان على nginx)

22

لذا فقد وجدت أخيرًا الوقت للعمل على أدلة “إعداد Let’s Encrypt مع نطاقات متعددة” و"توجيه نطاق واحد/عدة نطاقات إلى مثيل Discourse الخاص بك".

لقد أضفت الكثير إلى ملف containers/app.yml أكثر مما أضفت أنت، ويبدو أن كل شيء يعمل بشكل صحيح تقريبًا.

يتم استضافة Discourse الخاص بي على النطاق الفرعي www، وكان هدفي توجيه طلبات http و https من النطاق الرئيسي (apex domain) إلى النطاق الفرعي www. وهذا يعمل الآن، ولكن إذا ذهبت إلى https://mydomain.com، فسيتم التوجيه، لكن Chrome يظهر التحذير التالي في وحدة التحكم:

Redirecting navigation example.com -> www.example.com because the server presented a certificate valid for www.example.com but not for example.com. To disable such redirects launch Chrome with the following flag: --disable-features=SSLCommonNameMismatchHandling

إليك الإضافات الخاصة بي في ملف app.yml:

 after_ssl:
    - replace:
        filename: "/etc/runit/1.d/letsencrypt"
        from: /--keylength/
        to: "-d example.com -d www.example.com --keylength"
    - replace:
        filename: "/etc/nginx/conf.d/discourse.conf"
        from: /return 301 https.+/
        to: |
          return 301 https://$host$request_uri;
    - replace:
        filename: "/etc/nginx/conf.d/discourse.conf"
        from: /gzip on;[^\}]+\}/m
        to: |
          gzip on;
          add_header Strict-Transport-Security 'max-age=31536000'; # تذكر الشهادة لمدة عام واتصل تلقائيًا بـ HTTPS لهذا النطاق
  after_web_config:
    - replace:
        filename: /etc/nginx/nginx.conf
        from: /sendfile.+on;/
        to: |
          server_names_hash_bucket_size 64;
          sendfile on;
    - file:
      path: /etc/nginx/conf.d/discourse_redirect_1.conf
      contents: |
        server {
          listen 80;
          listen 443 ssl;
          server_name example.com;
          return 301 https://www.example.com$request_uri;
        }

هل يبدو هذا صحيحًا؟ إذا كان الأمر كذلك، فهل هناك حل لمشكلة عدم تطابق اسم الشهادة؟

تعديل: لدي سجلان من نوع A، أحدهما للنطاق الفرعي www والآخر يستخدم @ لالتقاط جميع الطلبات الموجهة إلى النطاق الرئيسي. كلاهما يشير إلى عنوان IP الخاص بـ Digital Ocean droplet الخاص بي. أفترض أن هذا صحيح أيضًا؟

شكرًا لك.

23

مجانية التطبيق، حتى لو لم يكن Cloudflare مسجّلك للنطاق. تعمل مع HTTPS، دون تعقيد إضافي في تثبيت Discourse الخاص بك.

24

شكرًا لك، أنا لا أستخدم Cloudflare حاليًا لذا لم أصادف تلك من قبل. سلكت مسارًا مختلفًا واتبعت الأدلة المذكورة أعلاه ونجحت إلى حد كبير في حل مشكلتي. لقد نشرت في الوقت الذي كنتُ أقدّم فيه ردّي أعلاه.

25

يرجى التحقق من هذا الموقع؛ هل يحتوي على جميع إعادة التوجيه التي تحتاجها؟ تم ذلك باستخدام كتلة replace واحدة فقط (انظر أعلاه) وإعدادات DNS هذه (لقد قمت بإخفاء سجلات TXT الخاصة بالبريد الإلكتروني فقط):

image
image1421×550 14.9 KB

لا أحصل على أي تحذير في وحدة التحكم.

26

نعم، فقط كن مستعدًا لحدوث خلل عند تغيير إعدادات Let’s Encrypt.

عندما تم تحديث Let’s Encrypt لدعم المنحنيات الإهليلجية، تعطلت الطريقة التي تعتمد عليها أعلاه لبضعة أسابيع.

28

الفرق الوحيد هو أنني لا أملك سجل CAA في DNS الخاص بي. سأضيفه باستخدام نفس القيمة التي استخدمتها.

أفترض أن اسم المضيف الخاص بـ Discourse هو www.example.com، هل أنت متأكد من عدم ظهور تحذير عند الدخول إلى https://example.com؟

التحذير أكثر حدة في متصفح Chrome على أندرويد، حيث يقوم بحظر الموقع بالكامل دون إعادة توجيه.

29

لقد فقدتُك الآن :slight_smile: ما الذي يجب أن أنتبه إليه أو أكون مستعدًا لإصلاحه؟

30

صحيح.

نعم، أنا متأكد، لا يوجد تحذير في وحدة التحكم.

31

أعتقد أنني عثرت على المشكلة، كان لدي هذا:

after_ssl:
    - replace:
        filename: "/etc/runit/1.d/letsencrypt"
        from: /--keylength/
        to: "-d example.com -d www.example.com --keylength"

بينما كان يجب أن يكون لدي:

after_ssl:
    - replace:
        filename: "/etc/runit/1.d/letsencrypt"
        from: /--keylength/
        to: "-d example.com --keylength"

لاحظ السطر الأخير، كان لدي example.com و www.example.com

كما قمت بتغيير return 301 https://$host$request_uri; إلى return 301 $scheme://$host$request_uri; وبعد إعادة البناء يبدو أن الأمر يعمل الآن.

الآن أنا قلق فقط بشأن ما ذكره @Stephen حول احتمال حدوث خلل عند تغيير إعدادات letsencrypt..

32

تغيير حدث في 9 سبتمبر من العام الماضي خرق النهج الذي تتبعه، وبما أن التنفيذ يقع خارج التثبيت القياسي، لم يتم نشر الحل حتى 31 أكتوبر. إذا نظرت إلى الموضوع الذي اتبعته وسجل التعديلات في الويكي، فسيكون الأمر موثقًا بوضوح.

بما أنك لا تقوم بشيء يستدعي الغوص في إعدادات إضافية، فإنني أنصحك بعدم القيام بذلك. من ناحية أخرى، عندما يحدث تغيير في Let’s Encrypt وتتأثر به، يمكننا إرجاعك إلى هذا الموضوع.