Would simple proxy_set_header X-Forwarded-Proto https; work?
The http/s request comes from the container to the IDP server for Discourse ID on the internet. There is no instance between where I could add/change any request headers.
IMHO and assuming that “Discourse ID” is just standard OAuth, the correct way would be either
a) a configuration option for discourse ID where I could add a “well-known” configuration endpoint which has all required OIDC configuration values, including the “https://… prefix.
b) the same, but already hardcoded into the code
I’m still puzzling over the technical details of Discourse ID …
You can look up the details of the Discourse ID in our code, the protocol we use is all there in our Github repository. The only difference with other OAuth implementations is that we auto-register an instance. And during that auto-registration, we make sure that the instance requesting to register is who it says it is and is on https (in this day and age, no Discourse instance should be on http://).
The http errors I shared above tell me that your site isn’t properly configured.
Can you check the output of the following via the console:
Discourse.base_url
SiteSetting.force_https
If you get a http:// URL from the first command and false from the second, you might want to set SiteSetting.force_https = true and see if that fixes it. (It might also break things if the configuration is incorrect in other places, though. Beware.)
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.
Thomas, sorry, I can’t really help you with your specific setup. All I can say is that something in your instance is incorrect.
Well, the JS console on your site doesn’t think that the https encryption outside of the container is covering everything. Those JS warnings I shared above are symptoms of a similar problem you are having with ID, Discourse itself in your setup thinks it is running in http and that is a problem, because it will generate URLs in http in some cases.
1 me gusta
Penar, big big big sorry:
I compared settings on our productive instance (PROD) with the ones on the DEV instance. Only the DEV instance had disabled the force_https setting. And this only worked because we have the SSL haproxy SSL accelerator in front of it.
I now activated the SiteSetting.force_http n the DEV instance and discourse ID works fine. Thus I will also deploy Discourse ID on our PROD instance (forum.netzwissen.de).
Sorry for the confusion.
2 Me gusta
No worries, glad it’s sorted out. Thanks for following up!
1 me gusta