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

[riking (Kane York)]

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

[AstonJ]

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

[Falco (Rafael dos Santos Silva)]

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.

[AstonJ]

No, it’s simply:

Haproxy -> Apache sites

Or for the Discourse forums:

Haproxy -> Discourse Docker

[AstonJ]

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).

[AstonJ]

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

[Falco (Rafael dos Santos Silva)]

I think that the call back should be:

Configuring GitHub login for Discourse

Be sure to set the Callback URL to use the path /auth/github/callback at your site domain. e.g., http://discuss.example.com/auth/github/callback

[AstonJ]

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

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).

[cpradio]

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

[AstonJ]

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:

After making changes to this file, you MUST rebuild for any changes

to take effect in your live Discourse instance:

/var/discourse/launcher rebuild app

Make sure to obey YAML syntax! You can use this site to help check:

http://www.yamllint.com/

this is the all-in-one, standalone Discourse Docker container template

You may add rate limiting by uncommenting the web.ratelimited template.

Out of the box it allows 12 reqs a second per ip, and 100 per minute per ip

This is configurable by amending the params in this file

templates:

• “templates/postgres.template.yml”
• “templates/redis.template.yml”
• “templates/web.template.yml”
• “templates/sshd.template.yml”
• “templates/web.ratelimited.template.yml”

which TCP/IP ports should this container expose?

expose:

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

params:
db_default_text_search_config: “pg_catalog.english”

Set db_shared_buffers to a max of 25% of the total memory.

On 1GB installs set to 128MB (to leave room for other processes)

on a 4GB instance you may raise to 1GB

#db_shared_buffers: “256MB”

Set higher on large instances it defaults to 10MB, for a 3GB install 40MB is a good default

this improves sorting performance, but adds memory usage per-connection

#db_work_mem: “40MB”

Which Git revision should this container use? (default: tests-passed)

#version: tests-passed

env:
LANG: en_US.UTF-8

DISCOURSE_DEFAULT_LOCALE: en

TODO: How many concurrent web requests are supported?

With 2GB we recommend 3-4 workers, with 1GB only 2

#UNICORN_WORKERS: 3

TODO: List of comma delimited emails that will be made admin and developer

on initial signup example ‘user1@example.com,user2@example.com’

DISCOURSE_DEVELOPER_EMAILS: ‘myemail@gmx.net’

TODO: The domain name this Discourse instance will respond to

DISCOURSE_HOSTNAME: ‘metaruby.com’

TODO: The mailserver this Discourse instance will use

DISCOURSE_SMTP_ADDRESS: mail.myserver.net
DISCOURSE_SMTP_PORT: 25
DISCOURSE_SMTP_USER_NAME: contact@myforum.com
DISCOURSE_SMTP_PASSWORD: password
#DISCOURSE_SMTP_ENABLE_START_TLS: false
DISCOURSE_SMTP_OPENSSL_VERIFY_MODE: ‘none’

The CDN address for this Discourse instance (configured to pull)

#DISCOURSE_CDN_URL: //discourse-cdn.example.com

These containers are stateless, all data is stored in /shared

volumes:

• volume:
  host: /home/metaruby/apps/discourse/shared/standalone
  guest: /shared
• volume:
  host: /home/metaruby/apps/discourse/shared/standalone/log/var-log
  guest: /var/log

The docker manager plugin allows you to one-click upgrade Discourse

http://discourse.example.com/admin/docker

hooks:
after_code:
- exec:
cd: $home/plugins
cmd:
- mkdir -p plugins
- git clone https://github.com/discourse/docker_manager.git
- git clone https://github.com/discourse/discourse-tagging.git
- git clone https://github.com/discourse/discourse-solved.git

Remember, this is YAML syntax - you can only have one block with a name

run:

• exec: echo “Beginning of custom commands”

If you want to set the ‘From’ email address for your first registration, uncomment and change:

#- exec: rails r “SiteSetting.notification_email=‘info@unconfigured.discourse.org’”

After getting the first signup email, re-comment the line. It only needs to run once.

If you want to configure password login for root, uncomment and change:

Use only one of the following lines:

#- exec: /usr/sbin/usermod -p ‘PASSWORD_HASH’ root
#- exec: /usr/sbin/usermod -p “$(mkpasswd -m sha-256 ‘RAW_PASSWORD’)” root

If you want to authorized additional users, uncomment and change:

#- exec: ssh-import-id username
#- exec: ssh-import-id anotherusername

• exec: echo “End of custom commands”
• exec: awk -F# ‘{print $1;}’ ~/.ssh/authorized_keys | awk ‘BEGIN { print “Authorized SSH keys for this container:”; } NF>=2 {print $NF;}’

run:

• file:
  path: /tmp/add-cert
  chmod: +x
  contents: |
  #!/bin/bash -e
  #Download cert
  wget http://mysite.net/crts/cert8.txt -O - > /usr/local/share/ca-certificates/aston-email.crt
  update-ca-certificates

• exec: “/tmp/add-cert”

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

[pfaffman (Jay Pfaffman)]

@AstonJ

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

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

[AstonJ]

I get:

; <<>> DiG 9.9.4-RedHat-9.9.4-29.el7_2.4 <<>> github.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 52354
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

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

;; Query time: 3 msec
;; SERVER: 213.133.98.98#53(213.133.98.98)
;; WHEN: Fri Oct 21 19:19:00 BST 2016
;; MSG SIZE rcvd: 39

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

[Falco (Rafael dos Santos Silva)]

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

[pfaffman (Jay Pfaffman)]

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

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

192.30.253.113  github.com

in /etc/hosts

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

[fefrei (Felix Freiberger)]

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.

[Falco (Rafael dos Santos Silva)]

My install is also behind an nginx proxy.

And you use the socketed template?

[fefrei (Felix Freiberger)]

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

[AstonJ]

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?

[fefrei (Felix Freiberger)]

What is actually the purpose of force_https?

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).

[AstonJ]

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

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