¿Funcionaría el proxy_set_header X-Forwarded-Proto https; simple?
La solicitud http/s proviene del contenedor al servidor IDP para Discourse ID en Internet. No hay ninguna instancia intermedia donde pueda agregar/cambiar ninguna cabecera de solicitud.
En mi humilde opinión y asumiendo que “Discourse ID” es solo OAuth estándar, la forma correcta sería o bien
a) una opción de configuración para Discourse ID donde pudiera agregar un punto final de configuración “well-known” que tenga todos los valores de configuración OIDC requeridos, incluido el prefijo “https://…”.
b) lo mismo, pero ya codificado en el código
Todavía estoy dándole vueltas a los detalles técnicos de Discourse ID…
Puedes buscar los detalles del ID de Discourse en nuestro código, el protocolo que usamos está todo en nuestro repositorio de Github. La única diferencia con otras implementaciones de OAuth es que registramos automáticamente una instancia. Y durante ese registro automático, nos aseguramos de que la instancia que solicita registrarse sea quien dice ser y esté en https (en estos tiempos, ninguna instancia de Discourse debería estar en http://).
Los errores http que compartí anteriormente me dicen que tu sitio no está configurado correctamente.
¿Puedes verificar la salida de lo siguiente a través de la consola?
Discourse.base_url
SiteSetting.force_https
Si obtienes una URL http:// del primer comando y false del segundo, podrías considerar establecer SiteSetting.force_https = true y ver si eso lo soluciona. (Sin embargo, también podría romper cosas si la configuración es incorrecta en otros lugares. Ten cuidado).
1 me gusta
Hola Penar,
quizás primero tengamos que aclarar los detalles de mi configuración. Es un poco diferente en comparación con la implementación estándar.
- Un balanceador de carga central (https://www.haproxy.org/) que actúa como acelerador SSL para varios servicios web diferentes (no solo para Discourse). El acceso desde Internet a cualquiera de estos servicios solo está permitido a través de https. El cambio de http a https se realiza en el propio balanceador de carga, véase Redirect HTTP to HTTPS in a Few Easy Steps with HAProxy como referencia)
- haproxy reenvía las solicitudes del frontend al backend en una red privada (10.x.x.x) sin cifrado. Este tráfico termina en un nginx local en el host de docker.
- nginx reenvía las solicitudes al socket http del contenedor
web_onlyconproxy_pass ``http://unix``:/mnt/data/discourse/shared/web-only/nginx.http.sock
(Estoy utilizando una configuración de dos contenedores con web_only.yml y data.yml). Véase templates/web.socketed.template.yml como referencia.
No necesito SiteSetting.force_https, ya que todo el cifrado https se realiza fuera del contenedor de Discourse. Ya utilizo OAuth basado en el plugin Discourse OpenID Connect (OIDC) y con mi propio IDP. El plugin Discourse OIDC contiene una configuración para el “well-known” OpenID Connect discovery document. En mi caso: https://login.netzwissen.de/realms/netzwissen/.well-known/openid-configuration
Si Discourse ID implementara algo similar para el enlace entre la instancia del contenedor de Discourse y el IDP de Discourse ID, no habría problemas. Como “Discourse ID” utiliza un IDP fijo, una “URL well-known” de este tipo podría incluso codificarse de forma fija, incluido el prefijo https.
Thomas, lo siento, no puedo ayudarte realmente con tu configuración específica. Todo lo que puedo decir es que algo en tu instancia es incorrecto.
Bueno, la consola de JavaScript de tu sitio no piensa que el cifrado https fuera del contenedor lo cubra todo. Esas advertencias de JavaScript que compartí anteriormente son síntomas de un problema similar que tienes con la ID, el propio Discourse en tu configuración piensa que se está ejecutando en http y eso es un problema, porque generará URLs en http en algunos casos.
2 Me gusta
Gran, gran, gran disculpa:
Comparé la configuración de nuestra instancia productiva (PROD) con las de la instancia DEV. Solo la instancia DEV tenía desactivada la configuración force_https. Y esto solo funcionó porque tenemos el acelerador SSL haproxy delante.
Ahora he activado SiteSetting.force_http en la instancia DEV y Discourse ID funciona bien. Por lo tanto, también implementaré Discourse ID en nuestra instancia PROD (forum.netzwissen.de).
Disculpas por la confusión.
3 Me gusta
No te preocupes, me alegra que se haya solucionado. ¡Gracias por dar seguimiento!
2 Me gusta