Solicitudes de fuentes inseguras

Soporte
1 
Contenido mixto: La página en '\u003cURL\u003e' se cargó a través de HTTPS, pero solicitó una fuente insegura '\u003cURL\u003e'. Esta solicitud ha sido bloqueada; el contenido debe servirse a través de HTTPS

Y 40 solicitudes de fuentes del gem discourse-fonts. Esta es una instalación nueva donde Postgres y Redis se ejecutan en un servidor separado dentro de la red local y la conexión está “socketed” pero se sirve al exterior a través de https, por supuesto. Hay hilos similares pero ninguna respuesta clara para mí. La verificación de CSS apunta a wizard.scss (con mapeo de origen). ¿Alguna pista?

2

¿Habilitaste la configuración de forzar https?

1 me gusta
3

Lo más probable es que no. ¿Dónde lo configuro? ¿Y por qué debería ser necesario en primer lugar en lugar de que la solicitud CSS de recursos estáticos a través de https o referencias relativas?

FWIW: en el servidor web externo tengo la típica configuración 301.

Edición:

Encontré la configuración basándome en esta publicación, gracias @Arkshine

1 me gusta
4

No estoy seguro de por qué tienes un enlace http en algún lugar; se debe aplicar https independientemente.

Puedes encontrarlo en la barra de búsqueda:

image
image861×193 6.81 KB

2 Me gusta
5

Bueno, yo tampoco. No modifiqué nada. Solo el launcher build app habitual. Estas URL parecen estar en el CSS procesado, que obviamente no toqué (ni el scss) de ninguna manera. Tampoco encontré nada relacionado con https en el app.yml, así que… no sé. El force_https parece solucionar el problema.

1 me gusta
6

FORCE_HTTPS le indica a Discourse que reescriba las solicitudes.

Es necesario incluso si estás haciendo encapsulación SSL fuera del contenedor para evitar el problema que estás describiendo.

1 me gusta
7

Depende de cómo definamos “necesario”. Actualmente podría ser necesario solucionar el problema real, que es que los archivos CSS compilados hacen referencia a activos estáticos explícitamente usando el esquema http. Pero en mi opinión, esto no debería ser necesario a largo plazo.

8

Necesario, ya que es el propósito de FORCE_HTTPS: así es como le dices a Discourse que se está sirviendo de forma segura y que reescriba los enlaces en consecuencia.

9

¿Qué factores/condiciones afectarían el protocolo HTTP/HTTPS de la URL de los activos (JS/CSS)?

  1. Si comentas lo siguiente y tu sitio accede desde HTTP, entonces la URL de los activos también será HTTP
  #- "templates/web.ssl.template.yml"
  #- "templates/web.letsencrypt.ssl.template.yml"

En este caso, si habilitas force_https, terminarás con todos los errores de URL de activos R_SSL_PROTOCOL_ERROR si el dominio solicitado no tiene un certificado instalado. Luego, para evitar eso, instalas un certificado para resolver el problema del protocolo SSL.

  1. Si en su lugar instalas Discourse con la plantilla anterior descomentada, la URL de los activos del sitio debería ser HTTPS junto con el protocolo de la URL base de tu sitio. Y además, force https es invisible en la interfaz de administración.
10

Como se mencionó en la publicación original, en mi caso el certificado y todo es correcto y válido, pero todas las conexiones al exterior son manejadas por un proxy inverso (nginx, obviamente ;-)), mientras que la conexión a Discourse se realiza a través de un socket Unix. Esto significa que tengo
templates/web.socketed.template.yml
en lugar de cualquiera de los que mencionas. Aun así, esto no debería hacer que las URL estáticas tengan un esquema http: explícito codificado.

11

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.