Как ослабить политику Content Security Policy

Разработка
1

Привет

Я хотел бы провести тестирование Discourse, не обязательно используя его настроенное публичное доменное имя. Например, если Discourse установлен и настроен как https://uat.mysite.com, то я, конечно, могу открыть браузер и перейти по адресу https://uat.mysite.com. В этом случае мой браузер выйдет из моей внутренней сети в публичный интернет, чтобы разрешить доменное имя до его публичного IP-адреса, и загрузит страницы через этот публичный IP.

Я только что попробовал открыть Discourse через внутренний IP-адрес сервера (например, 192.168.1.2, показанный ниже), и, как и следовало ожидать, он не загрузился из-за политики безопасности контента (Content Security Policy). Ошибки, которые я получаю, имеют следующий вид:

Загрузка скрипта 'http://192.168.1.2:12000/assets/locales/en-a9c88e45eb548bd7c807aecfd37d218891e213b5c1fd254857e0f16c72d73996.js' отклонена, так как это нарушает следующую директиву политики безопасности контента: "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='". Обратите внимание, что 'script-src-elem' явно не установлен, поэтому в качестве резервного варианта используется 'script-src'.

                                           ---------------------------------------------
                                          |                                             |
                                           ------------
uat.mysite.com разрешается в 98.1.2.3 -->   |  Публичный IP |  Сервер с запущенным Discourse.     |
                                          |  96.1.2.3. |
                                           ------------                                 |
                                          |                                             |
                                          |                  ----------------           |
                                          |                  |  Частный IP  |           |
                                          |                  | 192.168.1.2  |           |
                                           ---------------------------------------------
                                                                         ^
                                                                         |
192.168.1.2   ------------------------------------------------------------

Причина, по которой я хочу получить доступ к Discourse через внутренний IP-адрес сервера, заключается в том, что я хочу проводить тестирование. Например, если я хочу провести нагрузочное тестирование, мне не обязательно нагружать сеть, обслуживающую интернет. Или, если я хочу установить тестовый экземпляр на свой ноутбук или сервер сборки без необходимости настройки DNS.

Я думаю, что всегда можно обойти это, добавив пользовательскую запись в /etc/hosts, но есть ли способ либо отключить CSP, либо настроить её на доверие другим источникам для разрешения тестирования?

2

Это означает, что мой браузер выйдет из моей внутренней сети в публичный интернет, чтобы разрешить доменное имя в его публичный IP-адрес, и загрузит страницы через этот публичный IP-адрес.

Затем настройте свою машину так, чтобы она разрешала этот адрес в локальный IP-адрес сервера Discourse. Существует множество способов сделать это, но они зависят от операционной системы, поэтому при поиске в Google обязательно указывайте свою ОС. (В Linux и, как я полагаю, в macOS, достаточно просто отредактировать файл /etc/hosts.)

3

Я на самом деле пробовал использовать /etc/hosts, но из-за CSP ошибка сохраняется. Мне казалось, что существует флаг или настройка, позволяющая отключить это ограничение, чтобы разработчики могли выполнять все задачи на своём ноутбуке без необходимости разворачивать DNS-решение. Судя по статье Установка Discourse на macOS для разработки — документация / разработчики — Discourse Meta, процесс инициализации настраивается для работы с http://localhost:3000, а не с IP-адресом.

Проблема в том, что у меня есть автоматизация для установки Discourse, и я хочу использовать один и тот же процесс для развёртывания сред разработки, тестирования (UAT) и продакшена. При этом я не хочу, чтобы среда разработки была доступна из публичного интернета, хотя сейчас это, похоже, необходимо, так как требуется корректное разрешение полного доменного имени (FQDN). Существует несколько сценариев использования, один из которых — автоматическое еженедельное обновление Discourse в среде разработки и запуск серии тестов для проверки отсутствия сбоев.

В любом случае, если есть способ ослабить это требование и разрешить прямой доступ через IP, было бы полезно об этом узнать. В противном случае, полагаю, единственное решение — поднять небольшой DNS-сервис и настроить ноутбук на его использование, но это кажется довольно хлопотным.

4

Существует настройка сайта с названием content security policy. Вы можете снять галочку и сохранить, чтобы отключить CSP.

Пока это не сделано на рабочей инстансе, всё в порядке.

5

Это не лучшая идея. Это никогда не сработает. Среда разработки по необходимости отличается: в ней предварительно скомпилированы активы и выполнен ряд других действий, которые делают разработку невозможной в продакшен-среде. Если вы не разрабатываете плагины, вам вообще не нужна среда разработки. В таком случае вы можете использовать Docker-установку в качестве среды разработки, но это не то, что здесь называется «средой разработки».

Для развертывания сред тестирования (staging) и продакшена используйте Docker, как описано в стандартной инструкции по установке.

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 — лучший вариант; подробности для каждой ОС здесь.