Cómo relajar la Política de Seguridad de Contenido

Desarrollador
1

Hola

Me gustaría hacer algunas pruebas de Discourse sin tener que pasar necesariamente por su nombre de dominio público configurado. Por ejemplo, si Discourse se ha instalado y configurado como https://uat.mysite.com, entonces obviamente puedo abrir mi navegador y navegar a https://uat.mysite.com, lo que significa que mi navegador saldrá de mi red interna a Internet para resolver el nombre de dominio a su dirección IP pública y cargar las páginas a través de su dirección IP pública.

Acabo de intentar navegar a Discourse a través de la dirección IP interna del servidor (por ejemplo, 192.168.1.2 que se muestra a continuación) y, correctamente, no se carga debido a la Política de Seguridad de Contenido. Los errores que estoy recibiendo son de la siguiente forma.

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 se resuelve a 98.1.2.3 -->   |  IP Pública |  Servidor ejecutando Discourse.     |
                                          |  96.1.2.3. |
                                           ------------                                 |
                                          |                                             |
                                          |                  ----------------           |
                                          |                  |  IP Privada  |           |
                                          |                  | 192.168.1.2  |           |
                                           ---------------------------------------------
                                                                         ^
                                                                         |
192.168.1.2   ------------------------------------------------------------

La razón por la que me gustaría acceder a Discourse a través de la IP interna del servidor es porque quiero hacer pruebas. Por ejemplo, si quiero hacer pruebas de carga, no necesariamente quiero cargar el servicio de red que da servicio a Internet. O si quiero instalar una instancia de prueba en mi portátil o en un servidor de compilación sin tener que configurar DNS.

Supongo que siempre puedo anular esto estableciendo una entrada personalizada en /etc/hosts, pero ¿hay alguna forma de deshabilitar CSP o establecerlo para que confíe en otras fuentes para permitir las pruebas?

1 me gusta
2

Luego, configure su máquina para que resuelva esa dirección a la IP local del servidor de Discourse. Hay muchas maneras de hacerlo, pero dependen del sistema operativo, por lo que debe incluir el sistema operativo en su búsqueda en Google. (En Linux y creo que en Mac también, puede editar /etc/hosts.)

1 me gusta
3

De hecho, probé con /etc/hosts pero sigo teniendo el mismo error debido a CSP. Pensé que habría una opción o configuración que se pudiera usar para activarla y permitir que los desarrolladores hicieran todo dentro de su portátil sin tener que configurar una solución DNS. Al mirar la Instalar Discourse en macOS para desarrollo - documentación / desarrolladores - Discourse Meta, parece que se inicia algo que funciona con http://localhost:3000 en lugar de una IP.

El desafío que tengo es que tengo automatización para instalar Discourse y quiero usar el mismo proceso para configurar entornos de desarrollo, UAT y producción, y no necesariamente quiero que el entorno de desarrollo sea accesible desde Internet, lo que parece ser un requisito en este momento porque necesita resolver un FQDN adecuado. Hay múltiples casos de uso, uno de los cuales es, por ejemplo, automatizar la actualización de Discourse en el entorno de desarrollo cada semana y ejecutar una serie de pruebas para ver si algo se rompe.

De todos modos, si hay una manera de relajar el requisito para permitir el acceso directo a través de IP, sería bueno saberlo. De lo contrario, supongo que la única otra solución es poner en marcha un pequeño servicio DNS y luego configurar el portátil para usar el servicio DNS personalizado, pero parece ser un poco engorroso.

4

Hay una configuración del sitio llamada content security policy. Puede desmarcar y guardar para deshabilitar CSP.

Siempre que esto no se haga en una instancia de producción, está bien.

3 Me gusta
5

Eso no es una buena idea. Nunca funcionará. Un entorno de desarrollo es necesariamente diferente, ya que tiene activos precompilados y un montón de otras cosas que hacen imposible el desarrollo. A menos que estés desarrollando plugins, no necesitas un entorno de desarrollo en absoluto. Así que, si ese es el caso, entonces puedes tener tu entorno de desarrollo como una instalación de docker, simplemente no es lo que se llamaría un entorno de desarrollo aquí.

Quieres lanzar tus entornos de staging y producción usando docker como se describe en la instalación estándar.

3 Me gusta
6

¡Hola! Hago esto regularmente, pero con instalaciones de Docker. Suponiendo que utiliza nuestra instalación estándar de Docker en producción, entonces para sus pruebas de aceptación debería usar lo mismo. Hay un amplio margen para diferencias entre las instalaciones de desarrollo y Docker (configuración, versiones de gemas y paquetes de JS, etc.) que pueden convertirse en dolores de cabeza en el momento del despliegue.

Las instalaciones de Docker usan y fuerzan HTTPS por defecto. A menos que desee personalizar la plantilla del contenedor (lo cual he descubierto que tiene cierta complejidad oculta), puede simplemente desactivar la aplicación de HTTPS con otra configuración del sitio.

Este es mi fragmento para “relajar la seguridad en una instalación local de Docker”, que se puede revertir fácilmente antes de ir a producción:

SiteSetting.content_security_policy = false
SiteSetting.force_https = false

Luego, solo se trata de que su navegador pueda encontrar el puerto 80 en el contenedor de Docker en http://uat.mysite.com – tenga en cuenta que usará http en lugar de https.

Para eso, el truco de /etc/hosts de @pfaffman es el camino; detalles para cada sistema operativo aquí.

2 Me gusta