I’m hoping someone here will have the necessary insight/Discourse debugging fu to help me work out why my SSO efforts are failing…
The story so far: I have a Discourse instance (v1.7.0.beta6), running in a Docker container on Ubuntu Linux 14.04, serving via an HTTPS-configured nginx reverse proxy. I described the configuration previously. The HTTPS is provided by Let’s Encrypt certs. It has been running without issue for months now, using templates/web.template.yml and templates/web.ratelimited.template.yml - so between the nginx reverse proxy on the VM and the Docker container, traffic is going by HTTP, not HTTPS. All external traffic is automatically redirected to external port 443.
Now, I want to allow users to authenticate via an OAuth2 server provided by a multi-site WordPress instance I’m running on the same VM (not sure if this is relevant). It’s got the WP OAuth Server (full version, not gratis one). I’ve set up the client for my Discourse instance, and have configured all the URLs in both the WP Server’s config, i.e. the callback URL, and the various authorisation, token, and user URLs to be HTTPS. I also installed and rebuilt my Discourse instance with the https://github.com/discourse/discourse-oauth2-basic.git plugin.
Initially the OAuth process was failing at the callback URL from Discourse, with an error related to “OpenURI::HTTPError (400 Bad Request) /usr/local/lib/ruby/2.3.0/open-uri.rb:359:in `open_http’” via the logs… it seems as though perhaps it’s attempting to do the HTTPS via HTTP.
So I’ve now tweaked my nginx reverse proxy configuration to include
location @discourse2 {
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Host $host:443;
proxy_set_header X-Forwarded-Port 443;
proxy_redirect off;
add_header Front-End-Https on;
proxy_pass https://discourse2;
}
and this (discourse2 is the 2nd instance of Discourse running on this VM):
upstream discourse2 {
server 127.0.0.1:8443 fail_timeout=5;
}
and added the templates/web.ssl.template.yml to my app.yml, put copies of my Let’s Encrypt certs into the shared/ssl/ dir, configured new ports in apps.yml file - "127.0.0.1:8443:443" and and ran ./launcher rebuild app… The site, amazingly, works with this new configuration, and, with turning on force_https in Discourse’s security settings everything should be SSL end-to-end if I’m not mistaken…
And yet, I still can’t seem to get OAuth2 to work. I continue to get the open_http error, but am unable to work out what is going wrong. I note that the accompanying Request URI (from the logs) shows not just a single path, e.g. /auth/oauth2_basic/callback?code=aw1tb7i0n8zekhrh3i9ldhnzzbhdwzak4arw5dzz&state=d514fc06d5e5a32e1b8cc9c327f88571ff3a2ba83e6836c0 but a whole long list of them, presumably from prior test authorisation attempts, separated by commas. I include the one above, as it’s expired and doesn’t work in any case…
This look familiar to anyone? Is there a way to get this to work without enabling SSL in the Docker containers? For the record, I’ve read up on the thread where people are encountering roughly similar problems with Google’s OAuth2 service… but no major insights… Any thoughts gratefully accepted!
I found it by intercepting the HTTP request and doing some inspection on it.