Twitter, Github and normal username and password logins not working after upgrade

I’ve done that but it’s still http in the url :confused:

Btw, I’m not using web.ssl.template.yml as I thought there was no need if you are using something like nginix or haproxy on the front end (which handles the https side of things).

So you are terminating HTTPS at haproxy then right? And then sending HTTP to Discourse Docker?


Yes @cpradio

This is in my haproxy config (when it matches the url of my first Discourse forum):

backend discourse_docker
server server2 cookie A check
cookie JSESSIONID prefix no cache

And in my container:


  • “8888:80” # fwd host port 80 to container port 80 (http)
  • “2222:22” # fwd host port 2222 to container port 22 (ssh)

Full file here:

(I think all of this was set-up in this manner after the advice I got here on Meta.)

If you log in to your host and type


does it resolve? It’s not resolving anywhere that I can find.

; <<>> DiG 9.9.5-3ubuntu0.9-Ubuntu <<>>
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 17584
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

; EDNS: version: 0, flags:; udp: 512
;			IN	A

;; Query time: 5003 msec
;; WHEN: Fri Oct 21 14:13:00 EDT 2016
;; MSG SIZE  rcvd: 39


Right this minute and don’t find github and the ones of github’s DNS servers that I checked are unreachable. I’d wait a while before debugging this further

Tech Email:
Name Server:
Name Server:
Name Server:
Name Server:
1 Like

I get:

I’m not sure why GH being down would affect our normal username/password login tho?

One thing you can try, while you debug further: Disable force_ssl

1 Like

Oops. Yes. I missed that part, yes, it would seem that local logins should still work.

Anything that you need to do that involves a rebuild, though, will likely fail.

If you do need to rebuild, you can put

in /etc/hosts

But you should remember to take it out after this DDOS attack is over.

1 Like

I’m having the same issue, affecting both SSO and /users/admin-login logins.

I’m not sure what’s happening here. This is how things go:

  • I hit / via HTTPS without any cookies.
  • I am given a cookie like this: _forum_session=bVd; path=/; HttpOnly, and redirected to /session/sso. Makes sense!
  • I hit /session/sso via HTTPS, sending Cookie: _forum_session=bVd. Discourse responds with a redirect to my SSO URL, and sets a new cookie: _forum_session=VXd; path=/; HttpOnly. Why do I get a new cookie?
  • After a little dance with the SSO source, I hit /session/sso_login?sso=xxxxxx via HTTPS, sending Cookie: _forum_session=VXd with the request. Discourse redirects to /, sending a third cookie: Set-Cookie: _forum_session=QzB; path=/; HttpOnly
  • I hit / via HTTPS, the cookie is sent: Cookie: _forum_session=QzB. However, this is treated like an unauthenticated request, I’m issued a new cookie and sent to /session/sso again.

Disabling force_ssl fixes this. Note that all requests are made over HTTPS. Also note that the cookies aren’t actually marked as secure.

My install is also behind an nginx proxy.


And you use the socketed template?

Yes, I’m using exactly the setup described in my howto.

1 Like

Ok unchecking force_https seems to have brought log-ins back (at least the user/pw login - twitter and gh still down for me).

However I thought we needed force_https so that links and image urls are generated with https? (What is actually the purpose of force_https?)

Also, for some reason the forum seems to be a bit slower now - wonder if that’s related?

It definitely has one new purpose: To mark the cookies as secure, preventing them from being transferred unencrypted over a HTTP connection. But behind an nginx proxy, this doesn’t seem to work right now (in some scenarios).


Perhaps ‘secure cookies’ needs to be a separate option in the ACP?

@Falco and @cpradio, can you confirm what force_https does please?

I’m not seeing

    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto https;

in that How To can you try it?


I’ll have to defer to @Falco and @sam. I haven’t dug into the force_https setting and where it is utilized.

The former is in the #howto, the second… was the culprit :tada:

Now I get a secure _t cookie.

I still think this is a bug: If Discourse doesn’t see that the request came via HTTPS, it shouldn’t just drop the cookie entirely, but either still deliver the secure flag (it would have worked in my case!), or deliver the cookie without it.
(I prefer blindly delivering the secure flag. That feels intuitive, and there already is a HUGE warning that the site will break without proper HTTPS, so Discourse should just trust the user that HTTPS is handled, somewhere, period.)



Ok, so it’s solved and the problem was misconfigured reverse proxies.

Thanks for the testing @fefrei!

I can be wrong, but I think this is rails/rack business.


Changing the github callback to /auth/github/callback broke it - giving users this error:

Note uri-redirecti-missmatch in the url.

Putting it back to just (in github) and it’s working again. Is this odd?

1 Like

Just an update to say I followed @Falco’s advice:

and added:

reqadd X-Forwarded-Proto:\ https if { ssl_fc }

to the frontend http-in in Haproxy and it seems to be working now :thumbsup:

(I already had option forwardfor which is the same as X-Forwarded-For)

Thanks everyone! :slight_smile: