Olá Penar,
talvez precisemos esclarecer os detalhes da minha configuração primeiro. Ela é um pouco diferente em comparação com a implantação padrão.
- balanceador de carga central (https://www.haproxy.org/) atuando como acelerador SSL para alguns serviços web diferentes (não apenas para o Discourse). O acesso da Internet a qualquer um desses serviços só é permitido via https. A mudança de http para https é feita no próprio balanceador de carga, veja Redirect HTTP to HTTPS in a Few Easy Steps with HAProxy como referência)
- o haproxy encaminha as requisições front-end para o backend em uma rede privada (10.x.x.x) sem criptografia. Esse tráfego termina em um nginx local no host do docker.
- o nginx encaminha as requisições para o socket http do contêiner web_only com
proxy_pass ``http://unix``:/mnt/data/discourse/shared/web-only/nginx.http.sock
(Estou usando uma configuração de dois contêineres com web_only.yml e data.yml). Veja templates/web.socketed.template.yml como referência
Eu não preciso de SiteSetting.force_https, pois toda a criptografia https é feita fora do contêiner do Discourse. Eu já uso OAuth com base no plugin Discourse OpenID Connect (OIDC) e com meu próprio IDP. O plugin Discourse OIDC contém uma configuração para o “well-known” OpenID Connect discovery document. No meu caso: https://login.netzwissen.de/realms/netzwissen/.well-known/openid-configuration
Se o Discourse ID implementasse algo semelhante para o link entre a instância do contêiner Discourse e o IDP do Discourse ID, não haveria problemas. Como o “Discourse ID” usa um IDP fixo, tal “URL well-known” poderia até ser codificada, incluindo o prefixo https.