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

I upgraded the forum last night and this morning several members have emailed saying they can’t register (everything appears to work but when redirected back to the forum they are still shown the log-in/sign-up and can’t post etc).

I’ve tried using a Twitter log-in on one of our existing accounts and I get the same thing.

Anyone know how to troubleshoot this? There are no errors in the error log. The forum is at https://elixirforum.com

Edit: Normal username and password logins are not working either.

1 Like

Maybe it’s related?

3 Likes

I don’t think this is the issue because I managed to log in via Twitter to Discourse ok.

1 Like

And I managed to login with Github on Meta just now.

This looks like something with the new secure cookie. Is your setup just standard docker? I think you are on multisite right?

Is force_https on for you?

EDIT: Your redirect URI is http on Github Login, somehow. Here on meta is correctly set to https.

Still getting the same thing (changed github callback url to https://elixirforum.com).

I’m not using multisite, just multiple single containers.

Yep, force_https is selected.

I think it’s to do with the update : /

When logging with Github on Meta:

https://github.com/login?client_id=redacted&return_to=%2Flogin%2Foauth%2Fauthorize%3Fclient_id%redacted%26redirect_uri%3Dhttps%253A%252F%252Fmeta.discourse.org%252Fauth%252Fgithub%252Fcallback%26response_type%3Dcode%26scope%3Duser%253Aemail%26state%redacted

On Elixir Forum:

https://github.com/login?client_id=redacted&return_to=%2Flogin%2Foauth%2Fauthorize%3Fclient_id%redacted%26redirect_uri%3Dhttp%253A%252F%252Felixirforum.com%252Fauth%252Fgithub%252Fcallback%26response_type%3Dcode%26scope%3Duser%253Aemail%26state%redacted

Notice http VS https

2 Likes

Yeah, the redirect Uri is plain http. This is the secure cookies change

2 Likes

I just tried logging in with a normal username and password and that is not working either.

What is the secure cookies change and what do I need to do to fix it?

https://meta.discourse.org/t/secure-cookie-flag/28058/33?u=falco

We are adding necessary security on https enabled sites.

It can break if https isn’t set properly.

Go to your GitHub oauth settings and change the redirect URL to be https.

2 Likes

I set it to https earlier. But still, why would it affect normal username and password logins (which isn’t working either). Or Twitter?

I also just tried to rebuild one of the other forums… and that failed cos Could not resolve host: github.com; (which I guess is due to their current problems).

Can we switch this secure cookie update off via ACP or revert to an older version for the time being?

Edit: My set-up is detailed in this How To: How to set up Discourse on a server with existing Apache sites

So it’s:

Internet -> Haproxy -> Apache -> Docker -> Nginx -> Unicorn

When using something outside docker, I know it’s recommended make the inner nginx listen in a unix socket so stuff don’t break. However I don’t have much experience in your stack.

No, it’s simply:

Haproxy -> Apache sites

Or for the Discourse forums:

Haproxy -> Discourse Docker

1 Like

Why is this an unsupported install @Falco? It is a Docker install as normal - the only difference is Haproy on the front (as there is no other way to run ‘normal’ websites on the same server - or do you know what the supported method is of running normal sites on a server as well?).

Also is there any way I can roll back the discourse version to before these new secure cookies were introduced? (Without reverting to an older database).

Github is back online and it’s set to https:

I think that the call back should be:

1 Like

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?

2 Likes

Yes @cpradio

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

backend discourse_docker
server server2 127.0.0.1:8888 cookie A check
cookie JSESSIONID prefix no cache

And in my container:

expose:

  • “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

dig github.com

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


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

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;github.com.			IN	A

;; Query time: 5003 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Oct 21 14:13:00 EDT 2016
;; MSG SIZE  rcvd: 39

root@forum:/var/discourse# 

Right this minute 8.8.8.8 and 8.8.4.4 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: hostmaster@github.com
Name Server: ns2.p16.dynect.net
Name Server: ns3.p16.dynect.net
Name Server: ns4.p16.dynect.net
Name Server: ns1.p16.dynect.net
1 Like