Sitio movido detrás de proxy, favicon y encabezado ya no usan https

Soporte
1

I’ve since moved my Discourse instance between servers, and is now running behind a reverse proxy with SSL termination.

However, the header image and favicon are not being requested over HTTPS and getting blocked. I tried setting “force https” to on, but this hasn’t helped.

image
image.png1907×60 8.92 KB

1 me gusta
2

Is your proxy supplying an X-Forwarded-Proto header? (It should).

3 Me gusta
3

Is your proxy supplying an X-Forwarded-Proto header? (It should).

Yes it is.

1 me gusta
4

I had the same issue. I have a Discourse instance behind HAProxy with SSL termination. The fix is pretty simple, but not obvious:

  1. First make sure that “force https” is enabled in the settings (go to Settings and filter by “force https”).
  2. Go to Settings > Branding > and just re-upload your logos.
  3. Everything should use HTTPS now (be sure to hit your browser refresh button).

(I think this may be a bug in Discourse)

3 Me gusta
5

Hola,
Me gustaría retomar este asunto. En realidad, tengo el mismo problema y no puedo establecer force_https en true porque no hay forma de iniciar sesión… (Error desconocido en el inicio de sesión).
¿Cómo podemos obligar a que el logotipo se referencie mediante una solicitud HTTPS y no HTTP?
¿No debería ser sencillo?
Muchísimas gracias por su respuesta (he dedicado muchísimas horas a intentar solucionarlo).

6

Necesitarás cambiar la configuración del sitio force_https mediante SSH en el servidor e ingresar la línea de comandos de Ruby. Aquí hay temas de howto sobre cómo hacerlo.

7

Gracias por tu respuesta. Ciertamente no fui claro en mi mensaje. De hecho, logro cambiar force_https usando el comando de Rails, sin problema. Así que, para ser más claro:

Hasta la última actualización que realicé hace un par de días y que requirió reconstruir el contenedor de Docker, tenía una solución completamente funcional con force_https en true y con el siguiente parche que debía aplicar en la sección server del archivo de configuración de nginx para obtener un inicio de sesión válido:

  if ($http_x_forwarded_proto = 'http'){
    return 301 https://$host$request_uri;
  }

Y funcionaba. Sin embargo, desde la actualización, el mismo parche ya no me permite iniciar sesión, obteniendo el conocido “Unknown error”.

Obtuve el siguiente rastreo del registro de producción:

 Started POST "/session" for 193.134.222.4 at 2020-05-14 19:24:40 +0000
 Processing by SessionController#create as */*
 Parameters: {"login"=>"rossierd", "password"=>"[FILTERED]", "second_factor_method"=>"1", "timezone"=>"Europe/Zurich"}
 Can't verify CSRF token authenticity.
 Rendering text template
 Rendered text template (Duration: 0.0ms | Allocations: 1)
 Filter chain halted as :verify_authenticity_token rendered or redirected
 Completed 403 Forbidden in 2ms (Views: 0.7ms | ActiveRecord: 0.0ms | Allocations: 1101)

Cabe mencionar que nuestro contenedor de Discourse se ejecuta en una máquina virtual accesible a través de HTTPS.

¿Tienes alguna idea sobre la causa de este cambio de comportamiento antes y después de la actualización?

Hasta ahora, he desactivado force_https estableciéndolo en false; todo funciona bien, excepto el logotipo en la esquina superior izquierda (logotipo de la marca), que no aparece correctamente ya que se referencia mediante una solicitud http://…

Por cierto, aquí está la URL de nuestro sitio: https://discourse.heig-vd.ch

8

Además, también encontré la siguiente configuración del sitio que contiene la URL culpable:
SiteSetting.site_favicon_url (otra es SiteSetting.site_apple_touch_icon) con “http://…jpeg”.
Sin embargo, no parece obvio cambiar el valor con un simple comando de Rails, como hacemos con force_https, por ejemplo).

9

¿Alguna ayuda sobre este tema, por favor?

10

Esos se configuran mediante el asistente de configuración. Vuelva a ejecutar el asistente de configuración y vuelva a cargar las imágenes.

1 me gusta
11

He configurado las imágenes de esa manera. He vuelto a iniciar el asistente, pero con el mismo efecto al final :frowning:
Supongo que subir las imágenes no afecta a cómo se hacen referencia a ellas; es más bien algo relacionado con la generación de la página web.

12

Bueno, después de tantos intentos fallidos, finalmente descubrí cómo tener un inicio de sesión válido con force_https=true.

En el entorno de Docker, modifiqué /etc/nginx/conf.d/discourse.conf de la siguiente manera:

…
location @discourse {
limit_conn connperip 20;
limit_req zone=flood burst=12 nodelay;
limit_req zone=bot burst=100 nodelay;
proxy_set_header Host $http_host;
proxy_set_header X-Request-Start “t=${msec}”;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https; # $thescheme; <— Lo que modifiqué
proxy_pass http://discourse;
}
…

Y solo funciona en esta sección, al menos en mi entorno.

¡Ahora funciona genial!

1 me gusta