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.

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

[image] 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

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

[image] AstonJ: 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.

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.

[image] fefrei: My install is also behind an nginx proxy. And you use the socketed template?

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

Product Support Self-hosting

fefrei (Felix Freiberger) October 21, 2016, 7:01pm 26

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

Topic		Replies	Views
Avatar, Site Logos, and Cert Errors Self-hosting unsupported-install	61	6373	May 25, 2020
Mixed SSL since upgrade Self-hosting	13	978	December 30, 2022
Discourse lost the ability to login for all accounts Product Support	12	4030	October 21, 2016
Login not possible (no SSO, no LDAP, etc.) Product Support	2	1761	October 25, 2016
Authentication not working after a recent update Product Support	2	1994	October 26, 2016

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

Related topics