Hello,
I tried using Force https and it seemed to work for me except it was causing login problems. However, the logos are loaded using http by default. They should use the // protocol and let the browser decide which one to use, right? Or maybe there is another solution I’m missing?
Thanks
Hi Eddie,
What version of Discourse are you running? In recent versions logos are uploaded via site settings, instead of being linked using a URL, so this should no longer be an issue.
Hi Joshua, We recently upgraded to v2.2.5. During the previous upgrade, before force https, I believe I deleted the post where the logos were uploaded and switched to the site settings. Everything was fine. Then with v2.2.5, I can’t get rid of the http:// part without force https. I tried reuploading, the wizard, even modifying the images so their hash was different. No luck
Sorry, now I’m confused. Is force_https enabled or not? Is there any possibility you’re overriding the uploaded logos via themes? If your force_https is enabled, and your logos are served via site settings, there should not be a mixed content warning. Are you able to share a link to your site so I can take a look?
It was enabled, thought the upgrade was over. Then our QA reports that logins are not working. so we disabled force https for now. You can test here //forum.y8.com
I checked the themes and didn’t spot anything that might cause this https problem. We mostly use stock, though it is an old stock theme.
Con force_https desactivado, no puedo probar esto. Dependemos de esa configuración para garantizar que los recursos se sirvan a través de https, no de http. En cuanto al problema de inicio de sesión, parece que estás usando SSO, así que asegúrate de que la redirección de SSO desde tu proveedor enlace a tu sitio mediante https://, no http://. Una vez que vuelvas a activar force_https, podré echar otro vistazo.
This forum is using the oauth2 basic plugin. Maybe there is a problem with that, might require a version roll back. Not sure yet. I did check the settings, all addresses were using https, so no obvious problem there.
Tengo un problema similar aquí:
Después de descubrir que el logo y el icono grande se cargan mediante HTTP, lo que genera contenido mixto, habilitar force_https solucionó esto. Sin embargo, el inicio de sesión ya no era posible, lo que provocaba un bucle de redirección. Tras deshabilitar esta opción, el inicio de sesión vuelve a funcionar.
¿Por qué está ocurriendo esto?
¿Y por qué solo esas dos imágenes se cargan mediante HTTP, mientras que todos los demás recursos se cargan correctamente mediante HTTPS?
¿Cuál es tu método de inicio de sesión? ¿Asumo que no es un inicio de sesión local (nombre de usuario/contraseña)?
¿Hay algún proxy u otro servicio frente a su instalación?
Estoy usando SSO a través de otra aplicación web.
nginx se utiliza como proxy inverso.
¿Cómo se configuró nginx?
Nginx está redirigiendo todas las solicitudes HTTP a HTTPS, por lo que de todos modos no debería ser posible cargar contenido mediante HTTP.
Mi primera idea sería verificar dos veces tu configuración de SSO para ver a dónde redirige a los usuarios, así como qué orígenes acepta. Asegúrate de que todo dentro de la configuración de SSO esté usando https://. También es posible que esto sea un problema de Nginx. Va a ser difícil depurar aquí con múltiples variables…
Tengo exactamente el mismo problema que las personas que informan aquí y en este hilo.
El problema no está relacionado con la implementación de SSO ni con el servidor web: en mi caso, las solicitudes HTTP se redirigen a HTTPS, que luego se envían a través del proxy inverso. SSO funciona perfectamente si redirijo al usuario a https://discourse.fqdn.top/session/sso_login?sso=PAYLOAD&sig=SIGNATURE y force_https está en false. Esto demuestra que tanto la parte de SSO como el proxy funcionan perfectamente. Solo cuando cambio force_https a true, deja de funcionar. Cuando tengo una sesión previa, puedo cambiar force_https a true y usar Discourse sin ningún problema (lo que refuerza aún más el punto de que el problema no está relacionado con el proxy inverso). Dejar force_https en false no es una opción, ya que rompe los logotipos y Chrome no está contento cuando se mezclan activos de HTTP y HTTPS (muestra una pequeña alerta en la barra de direcciones indicando que la página no es segura).
¿Cómo es tu configuración de nginx y tienes un encabezado X-Forwarded-Proto en ella?
Muchas gracias. Sí; eso solucionó el problema. Así que sí estaba relacionado con el proxy. Perdón por asumir lo contrario, solo porque el contenido se cargó.
Por el bien de la exhaustividad, estoy usando Apache como proxy inverso y no nginx. Aquí están las líneas de configuración relevantes:
RequestHeader set X-Forwarded-Proto "https"
ProxyPass / http://[::1]:2045/ retry=10
ProxyPassReverse / http://[::1]:2045/
Agregar la primera línea solucionó el problema.
Hola,
perdona que vuelva a mencionar esto, pero en realidad no logro eliminar las advertencias de contenido mixto en Firefox. Lo curioso es que tengo una configuración bastante similar… más o menos. Quizás alguien pueda aportar algunas ideas o mejoras. No soy un gran experto en las directivas de Apache, pero tiene sentido para mí, al menos un poco.
Tenemos Discourse en Docker detrás de Apache mediante un proxy inverso y gestionamos los certificados de Let’s Encrypt con ISPConfig, ya que tenemos muchos dominios “normales” ejecutándose en nuestro servidor.
Configuramos el proxy inverso con directivas de Apache a través de ISPConfig. Nuestro setup se ve así:
ProxyPreserveHost On
ProxyPass /.well-known/acme-challenge !
RequestHeader set X-Forwarded-Proto "https"
ProxyPass / unix:///var/discourse/shared/standalone/nginx.http.sock|http://localhost/
ProxyPassReverse / unix:///var/discourse/shared/standalone/nginx.http.sock|http://localhost/
RewriteEngine On
RewriteCond %{HTTPS} !on
RewriteRule (.*) https://sub.domain.de$1 [R,L]
Aún tenemos advertencias de contenido mixto en Firefox. Lo que intenté fue activar la opción force ssl en la configuración. Como primer efecto, ya no podíamos iniciar sesión. Solo nos autenticamos con usuario y contraseña. Así que probé la solución mencionada:
Bien, ahora force ssl funciona y podemos iniciar sesión. Pero Firefox sigue mostrando advertencias de contenido mixto. La consola indica:
y
se sirven mediante HTTP… También intentamos volver a cargar esas imágenes de marca usando sub.domain.de/wizard, pero seguimos con este problema… ¿Hay alguna forma de… no sé, forzar la nueva renderización de las imágenes optimizadas usando HTTPS? ¿Hay algo mal en nuestra configuración del proxy inverso?
Agradecería mucho cualquier ayuda adicional aquí. Es como un océano de posibles configuraciones de proxy inverso con SSL forzado por Let’s Encrypt (gestionadas por) Apache (y no integradas en la configuración de Discourse), así que siento que me estoy ahogando. Y tengo la sensación de que hay muy pocas personas que usen Apache como host con un proxy inverso y la configuración de Let’s Encrypt que estamos utilizando. O quizás solo estamos configurándolo mal nosotros.
Como dije, agradecería cualquier sugerencia. ¡Gracias de antemano!
Intenta ejecutar SiteIconManager.ensure_optimized! desde una consola de Rails.
¡Vaya, qué respuesta tan rápida! Muchas gracias.
Bueno, mientras tanto… no sé si se activó porque pasó el tiempo y algo sucedió. Pero lo que hice después de enviar mi primer mensaje fue volver a subir esas dos imágenes (el favicon y el icono de Apple) sin usar el asistente, sino mediante la configuración de administración (personalización), y justo en ese momento quería cerrar la pestaña para volver a verificar si el inicio de sesión y todo funcionaban correctamente… ¿adivina qué? ¡Los errores de contenido mixto de Firefox desaparecieron!
¡Vaya!
Bueno, @RGJ, muchas gracias de nuevo. Creo que esto también solucionaría el redibujado de las imágenes optimizadas. ¿Crees que se activó en el meantime debido a un umbral de tiempo o por volver a subir las imágenes mediante el panel de administración, y no el asistente?
Gracias de nuevo, especialmente a @alphanoob1337 por finalmente lograr que esto funcione.
¡Vaya, qué inconveniente para un lunes irse del escritorio con una sensación agradable y feliz! 
