لا، لا يزال خلف وكيل عكسي، لقد وجدت للتو نموذجًا وبعض الطرق المختلفة للتعامل مع الخطاب. مع الاستمرار في استخدام طريقة التثبيت الرسمية.
سأقوم بعمل دليل قريبًا. فقط في حال احتاج أي شخص آخر لاستخدامه أو قد أحتاج إلى استخدامه مرة أخرى LOL.
هناك مشكلة صغيرة فقط نظرًا لأن تثبيتي لا يستخدم شهادة SSL الخاصة بـ letsencrypt. الرابط لتفعيل البريد الإلكتروني الذي تم إرساله يحتوي على http بدلاً من https. يوجد إعادة توجيه لجميع اتصالات http إلى https ولكنني أود فرض https من الواجهة الخلفية بحيث تحتوي جميع الروابط على https وليس http.
بهذه الطريقة، إذا تمكن أي شخص لديه حق الوصول إلى غرفة الخادم الخاصة بي لسبب ما. لا يمكنه ببساطة توصيل كابل إيثرنت ورؤية حركة المرور بوضوح. سيظل الاتصال يحتوي على HTTPS وسيصعب الأمر قليلاً على المتسلل. أحب أن تكون سلسلتي كاملة HTTPS. ليس WAN HTTPS → الوكيل العكسي HTTP → الواجهة الخلفية.
وإلا فسيكون ذلك مجرد أمان قشر البيض.
ثقة صفرية، بغض النظر عما إذا كنت أعرفك لمدة 10 سنوات+.
كل شيء آمن قدر الإمكان.
ألم تلاحظ أن معظم التسريبات تأتي دائمًا من الداخل. بهذه الطريقة أعرف أن أمان خادمي محكم وأن الثغرة الوحيدة ستكون البشر وموظفاي يفهمون ذلك بنسبة 100٪.
لدي عدد قليل من المستخدمين السحابيين البارزين وإذا خرجت بياناتهم لسبب خارق للطبيعة مع العلم أن أمان خادمي محكم. يمكنني بعد ذلك التحقق من الكاميرات ومعرفة من سيكون سبب تسرب البيانات بالضبط.
أعتقد أن AWS تفعل ذلك بطريقة مماثلة، مما رأيته. يجب أن تكون الثغرات البشرية دائمًا أولوية. بغض النظر عن مدى أمان خادمك. عصا USB واحدة وينتهي الأمر.
لأنه إذا لم تفعل ذلك، فسيقوم، على سبيل المثال، بإرسال روابط بريد إلكتروني ترتبط بـ http بدلاً من https، أو يرتبط بالصور باستخدام http بدلاً من https. إنه مضبوط افتراضيًا إذا كان يمكن لـ discourse معرفة أنه https؛ لست متأكدًا تمامًا من سبب عدم كونه افتراضيًا في هذه المرحلة، نظرًا لأن Discourse لا يعمل في الغالب إذا كانت هناك أي روابط http.
لا يتعلق الأمر بالاتصال بين الوكيل العكسي و Discourse ولكن الروابط التي ينشئها Discourse لنفسه.