Hi Penar,
maybe we have to clarify the details of my setup first. It is a bit different compared to the standard deployment.
- central load balancer (https://www.haproxy.org/) acting as ssl accelerator for multiple web services (not only Discourse). Access from the Internet to any of these services is only allowed via https. The switch from http to https is done on the load balancer itself, see Redirect HTTP to HTTPS in a Few Easy Steps with HAProxy for reference)
- haproxy forwards frontend requests to the backend on a private network (10.x.x.x) without encryption. This traffic terminates at a local nginx on the docker host.
- nginx forwards requests to the http socket of the web_only container with
proxy_pass ``http://unix``:/mnt/data/discourse/shared/web-only/nginx.http.sock
(I am using a two-container setup with web_only.yml and data.yml). See templates/web.socketed.template.yml for reference
I dont needSiteSetting.force_https, as all https encryption is done outside of the discourse container. I already use OAuth based on the Discourse OpenID Connect (OIDC) plugin and with my own IDP. The Discourse OIDC plugin contains a setting for the “well-known” OpenID Connect discovery documentIn my case: https://login.netzwissen.de/realms/netzwissen/.well-known/openid-configuration
If Discourse ID would implement something similar for the link between the Discourse container instance and the Discourse ID IDP, there would be no problems. As “Discourse ID” uses a fixed IDP such a “well-known URL” could even be hardcoded, including the https prefix.