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.