لقد أصلح هذا الالتزام (commit) خطأً في التكوين كنت تعتمد عليه، ولكنه أيضاً قد يكون سمح لأي مستخدم نهائي بتزوير عنوان الـ IP الخاص به عن طريق تعيين هذا الرأس (header).
إذا كنت واثقاً من أن لا شيء آخر يمكنه التواصل مع حاويتك، فهناك في الواقع طريقة أسهل لا تتطلب استخدام مقبس - لقد كتبت للتو دليلاً حول كيفية القيام بذلك.
بالنسبة لإعدادك @CLOUD_PHT، يجب أن تضيف هذا إلى تعريف الحاوية (إذا كانت هناك قسم run موجود بالفعل، أضف هذه التوجيهات إليه، وإلا أضف قسم run):
run:
- file:
path: /etc/nginx/conf.d/outlets/server/real-ip-header.conf
chmod: 644
contents: |
real_ip_header x-forwarded-for;
- file:
path: /etc/nginx/conf.d/outlets/server/set-real-ip-from-host.conf
chmod: 644
contents: |
set_real_ip_from 172.17.0.1;
قد تحتاج أيضاً إلى ما يلي:
- file:
# نحتاج إلى تفعيل التكرار (recursive) لأننا سنكون لدينا على الأقل إدخالين؛ واحد من المضيف، وواحد من CloudFlare
path: /etc/nginx/conf.d/outlets/server/real-ip-recursive.conf
chmod: 644
contents: |
real_ip_recursive on;
اعتماداً على ما إذا كان nginx الذي يعمل على خادمك يقوم بمعالجة رأس Cloudflare لتحديد عنوان IP الحقيقي للمستخدم النهائي (وهو ما يُقترح) أم يضيف فقط رأسه الخاص فوقه. راجع https://meta.discourse.org/t/handling-the-chain-of-trust-of-the-end-users-real-ip/406372#p-2001772-more-than-one-proxy-7 لمزيد من التفاصيل.
قراء آخرون: انتبهوا إلى أن هذا التوجيه
run:
- file:
path: /etc/nginx/conf.d/outlets/server/set-real-ip-from-host.conf
chmod: 644
contents: |
set_real_ip_from 172.17.0.1;
غير مناسب لجميع الإعدادات. لا تفعل هذا إلا إذا كانت جميع الاتصالات إلى حاوية Discourse من هذا العنوان موثوقة.
على وجه التحديد، مشكلة معروفة مع إعدادات IPv6 هي أن اتصالات IPv6 إلى الخادم يتم إعادة توجيهها بواسطة docker عبر IPv4 - الطريقة التي يتم بها ذلك تجعل جميع الاتصالات تبدو وكأنها قادمة من عنوان IP docker0 للمضيف. إذا طبقت التوجيه المذكور أعلاه على إعدادك، فسيسمح لجميع المستخدمين المتصلين عبر IPv6 بتزوير عنوان الـ IP الخاص بهم بكل سهولة.