كيفية استرخاء سياسة أمان المحتوى

مطور
1

مرحباً

أود إجراء بعض الاختبارات على Discourse دون الحاجة بالضرورة إلى المرور عبر اسم النطاق العام المُعد له. على سبيل المثال، إذا تم تثبيت Discourse وتكوينه على https://uat.mysite.com، فيمكنني بالطبع فتح متصفحي وتصفح https://uat.mysite.com، مما يعني أن متصفحي سيخرج من شبكتي الداخلية إلى الإنترنت العام لحل اسم النطاق إلى عنوان IP العام الخاص به، وتحميل الصفحات عبر عنوان IP العام الخاص به.

لقد حاولت للتو تصفح Discourse عبر عنوان IP الداخلي للخادم (مثل 192.168.1.2 الموضح أدناه) وبشكل صحيح لا يتم تحميله بسبب سياسة أمان المحتوى (Content Security Policy). الأخطاء التي أحصل عليها هي من الشكل التالي.

Refused to load the script 'http://192.168.1.2:12000/assets/locales/en-a9c88e45eb548bd7c807aecfd37d218891e213b5c1fd254857e0f16c72d73996.js' because it violates the following Content Security Policy directive: "script-src http://uat.mysite.com/logs/ http://uat.mysite.com/sidekiq/ http://uat.mysite.com/mini-profiler-resources/ http://uat.mysite.com/assets/ http://uat.mysite.com/brotli_asset/ http://uat.mysite.com/extra-locales/ http://uat.mysite.com/highlight_js/ http://uat.mysite.com/javascripts/ http://uat.mysite.com/plugins/ http://uat.mysite.com/theme-javascripts/ http://uat.mysite.com/svg-sprite/ 'sha256-rwfDVOTzygQmkOwFNAeX564B66beHoel4+gRLgQUgHg='". Note that 'script-src-elem' was not explicitly set, so 'script-src' is used as a fallback.

                                           ---------------------------------------------\
                                          |                                             |
                                           ------------\
uat.mysite.com resolves to 98.1.2.3 -->   |  Public IP |  Server running Discourse.     |
                                          |  96.1.2.3. |
                                           ------------                                 |
                                          |                                             |
                                          |                  ----------------           |
                                          |                  |  Private IP  |           |
                                          |                  | 192.168.1.2  |           |
                                           ---------------------------------------------\
                                                                         ^
                                                                         |
192.168.1.2   ------------------------------------------------------------

السبب الذي يجعلني أرغب في الوصول إلى Discourse عبر عنوان IP الداخلي للخادم هو أنني أريد إجراء الاختبارات. على سبيل المثال، إذا كنت أرغب في إجراء اختبار تحميل، فلا يلزم بالضرورة تحميل الشبكة التي تخدم الإنترنت. أو إذا كنت أرغب في تثبيت نسخة اختبار على الكمبيوتر المحمول الخاص بي أو خادم بناء دون الحاجة بالضرورة إلى إعداد DNS.

أعتقد أنه يمكنني دائمًا تجاوز هذا عن طريق تعيين إدخال مخصص في /etc/hosts، ولكن هل هناك طريقة لتعطيل CSP أو تعيينها للوثوق بمصادر أخرى للسماح بالاختبار؟

إعجاب واحد (1)
2

\n\n[quote=“titusc, post:1, topic:244459”]
مما يعني أن متصفحي سيخرج من شبكتي الداخلية إلى الإنترنت العام لحل اسم النطاق إلى عنوان IP العام الخاص به، وتحميل الصفحات عبر عنوان IP العام الخاص به.
[/quote]

إذًا، قم بتهيئة جهازك لحل هذا العنوان إلى عنوان IP المحلي لخادم Discourse. هناك العديد من الطرق للقيام بذلك، ولكنها تعتمد على نظام التشغيل، لذا يجب عليك تضمين نظام التشغيل في بحثك على Google. (في Linux وأعتقد أن Mac كذلك، يمكنك فقط تعديل /etc/hosts.)

إعجاب واحد (1)
3

لقد جربت بالفعل /etc/hosts ولكن لا يزال الخطأ نفسه بسبب CSP. كنت أعتقد أنه ستكون هناك علامة أو إعداد يمكن استخدامه لتبديل هذا لتمكين المطورين من القيام بكل شيء داخل أجهزتهم المحمولة دون الحاجة إلى إعداد حل DNS. بالنظر إلى تثبيت Discourse على macOS للتطوير - الوثائق / المطورين - Discourse Meta ، يبدو أنه يبدأ في شيء يعمل مع http://localhost:3000 بدلاً من عنوان IP.

التحدي الذي أواجهه هو أن لدي أتمتة لتثبيت Discourse وأريد استخدام نفس العملية لإعداد بيئات التطوير و UAT والإنتاج ولا أريد بالضرورة أن تكون بيئة التطوير متاحة للإنترنت العام، وهو ما يبدو أنه مطلب حاليًا لأنه يحتاج إلى حل اسم نطاق مؤهل بالكامل (FQDN). هناك حالات استخدام متعددة، أحدها هو، على سبيل المثال، أتمتة ترقية Discourse في بيئة التطوير كل أسبوع وتشغيل عدد من الاختبارات لمعرفة ما إذا كان أي شيء يتعطل.

على أي حال، إذا كانت هناك طريقة لتخفيف المتطلب للسماح بالوصول المباشر عبر عنوان IP، فسيكون من الجيد معرفتها. بخلاف ذلك، أعتقد أن الحل الوحيد الآخر هو إعداد خدمة DNS صغيرة ثم توجيه الكمبيوتر المحمول لاستخدام خدمة DNS المخصصة، ولكن يبدو هذا مزعجًا بعض الشيء.

4

يوجد إعداد موقع باسم content security policy. يمكنك إلغاء تحديده وحفظه لتعطيل CSP.

طالما أن هذا لم يتم في مثيل الإنتاج، فلا بأس.

3 إعجابات
5

هذه ليست فكرة جيدة. لن تنجح أبدًا. تختلف بيئة التطوير اختلافًا جوهريًا لأنها تحتوي على أصول مجمعة مسبقًا ومجموعة من الأشياء الأخرى التي تجعل التطوير مستحيلًا. ما لم تكن تقوم بتطوير إضافات، فلن تحتاج إلى بيئة تطوير على الإطلاق. لذلك، إذا كان هذا هو الحال، فيمكن أن تكون بيئة التطوير الخاصة بك تثبيت Docker، فهي ليست ما يسمى ببيئة تطوير هنا.

تريد إطلاق بيئات الاختبار والإنتاج الخاصة بك باستخدام Docker كما هو موضح في التثبيت القياسي.

3 إعجابات
6

مرحباً! أقوم بذلك بانتظام، ولكن مع تثبيتات Docker. بافتراض أنك تستخدم تثبيت Docker القياسي الخاص بنا في الإنتاج، فيجب عليك استخدام نفس الشيء لاختبارات القبول الخاصة بك. هناك هامش واسع للاختلافات بين تثبيتات التطوير و Docker (التكوين، إصدارات حزم gem و JS، إلخ) التي يمكن أن تتحول إلى صداع عند النشر.

تستخدم تثبيتات Docker بروتوكول HTTPS وتفرضه افتراضيًا. ما لم ترغب في تخصيص قالب الحاوية (والذي وجدته يحتوي على بعض التعقيد المخفي)، يمكنك ببساطة إيقاف فرض HTTPS باستخدام إعداد موقع آخر.

هذا هو المقتطف الخاص بي لـ “تخفيف الأمان في تثبيت Docker محلي”، والذي يمكن التراجع عنه بسهولة قبل الانتقال إلى الإنتاج:

SiteSetting.content_security_policy = false
SiteSetting.force_https = false

بعد ذلك، الأمر مجرد مسألة قدرة متصفحك على العثور على المنفذ 80 في حاوية Docker على http://uat.mysite.com - لاحظ أنك ستستخدم http بدلاً من https.

لذلك، فإن خدعة /etc/hosts الخاصة بـ @pfaffman هي الطريقة؛ التفاصيل لكل نظام تشغيل هنا.

إعجابَين (2)