# Twitter, Github and normal username and password logins not working after upgrade
**URL:** https://meta.discourse.org/t/twitter-github-and-normal-username-and-password-logins-not-working-after-upgrade/51854
**Category:** Self-hosting
**Tags:** unsupported-install
**Created:** [Outubro 21, 2016, 12:58pm UTC](https://meta.discourse.org/t/twitter-github-and-normal-username-and-password-logins-not-working-after-upgrade/51854 "2016-10-21T12:58:57Z")
**Posts on this page:** 16
**Page:** 2
### Author:  [@AstonJ](https://meta.discourse.org/u/AstonJ)
#### Post date: [Outubro 21, 2016, 6:23pm UTC](https://meta.discourse.org/t/twitter-github-and-normal-username-and-password-logins-not-working-after-upgrade/51854/21 "2016-10-21T18:23:48Z")
I get:
> [@](#):
>
> ; \<\<\>\> DiG 9.9.4-RedHat-9.9.4-29.el7\_2.4 \<\<\>\> [github.com](http://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](http://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?
---
### Author:  [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [Outubro 21, 2016, 6:31pm UTC](https://meta.discourse.org/t/twitter-github-and-normal-username-and-password-logins-not-working-after-upgrade/51854/22 "2016-10-21T18:31:02Z")
One thing you can try, while you debug further: Disable `force_ssl`
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [Outubro 21, 2016, 6:31pm UTC](https://meta.discourse.org/t/twitter-github-and-normal-username-and-password-logins-not-working-after-upgrade/51854/23 "2016-10-21T18:31:26Z")
> [@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.
---
### Author:  [@fefrei](https://meta.discourse.org/u/fefrei)
#### Post date: [Outubro 21, 2016, 6:32pm UTC](https://meta.discourse.org/t/twitter-github-and-normal-username-and-password-logins-not-working-after-upgrade/51854/24 "2016-10-21T18:32:51Z")
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.
---
### Author:  [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [Outubro 21, 2016, 6:59pm UTC](https://meta.discourse.org/t/twitter-github-and-normal-username-and-password-logins-not-working-after-upgrade/51854/25 "2016-10-21T18:59:33Z")
> [@fefrei](#):
>
> My install is also behind an nginx proxy.
And you use the socketed template?
---
### Author:  [@fefrei](https://meta.discourse.org/u/fefrei)
#### Post date: [Outubro 21, 2016, 7:01pm UTC](https://meta.discourse.org/t/twitter-github-and-normal-username-and-password-logins-not-working-after-upgrade/51854/26 "2016-10-21T19:01:12Z")
Yes, I’m using exactly the setup described [in my howto](https://meta.discourse.org/t/adding-an-offline-page-when-rebuilding/45238).
---
### Author:  [@AstonJ](https://meta.discourse.org/u/AstonJ)
#### Post date: [Outubro 21, 2016, 7:03pm UTC](https://meta.discourse.org/t/twitter-github-and-normal-username-and-password-logins-not-working-after-upgrade/51854/27 "2016-10-21T19:03:13Z")
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?
---
### Author:  [@fefrei](https://meta.discourse.org/u/fefrei)
#### Post date: [Outubro 21, 2016, 7:05pm UTC](https://meta.discourse.org/t/twitter-github-and-normal-username-and-password-logins-not-working-after-upgrade/51854/28 "2016-10-21T19:05:25Z")
> [@AstonJ](#):
>
> 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).
---
### Author:  [@AstonJ](https://meta.discourse.org/u/AstonJ)
#### Post date: [Outubro 21, 2016, 7:11pm UTC](https://meta.discourse.org/t/twitter-github-and-normal-username-and-password-logins-not-working-after-upgrade/51854/29 "2016-10-21T19:11:23Z")
Perhaps ‘secure cookies’ needs to be a separate option in the ACP?
@Falco and @cpradio, can you confirm what `force_https` does please?
---
### Author:  [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [Outubro 21, 2016, 7:12pm UTC](https://meta.discourse.org/t/twitter-github-and-normal-username-and-password-logins-not-working-after-upgrade/51854/30 "2016-10-21T19:12:07Z")
> [@fefrei](#):
>
> Yes, I’m using exactly the setup described in my howto.
I’m not seeing
```plaintext
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?
---
### Author:  [@cpradio](https://meta.discourse.org/u/cpradio)
#### Post date: [Outubro 21, 2016, 7:12pm UTC](https://meta.discourse.org/t/twitter-github-and-normal-username-and-password-logins-not-working-after-upgrade/51854/31 "2016-10-21T19:12:18Z")
> [@AstonJ](#):
>
> @Falco and @cpradio, can you confirm what force\_https does please?
I’ll have to defer to @Falco and @sam. I haven’t dug into the force\_https setting and where it is utilized.
---
### Author:  [@fefrei](https://meta.discourse.org/u/fefrei)
#### Post date: [Outubro 21, 2016, 7:26pm UTC](https://meta.discourse.org/t/twitter-github-and-normal-username-and-password-logins-not-working-after-upgrade/51854/32 "2016-10-21T19:26:20Z")
The former is in the #howto, the second… was the culprit 🎉
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.)
---
### Author:  [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [Outubro 21, 2016, 7:31pm UTC](https://meta.discourse.org/t/twitter-github-and-normal-username-and-password-logins-not-working-after-upgrade/51854/33 "2016-10-21T19:31:41Z")
🎉
Ok, so it’s solved and the problem was misconfigured reverse proxies.
Thanks for the testing @fefrei!
> [@fefrei](#):
>
> 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 can be wrong, but I think this is rails/rack business.
---
### Author:  [@AstonJ](https://meta.discourse.org/u/AstonJ)
#### Post date: [Outubro 22, 2016, 12:08am UTC](https://meta.discourse.org/t/twitter-github-and-normal-username-and-password-logins-not-working-after-upgrade/51854/34 "2016-10-22T00:08:09Z")
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 [forum-name.com](http://forum-name.com) (in github) and it’s working again. Is this odd?
---
### Author:  [@AstonJ](https://meta.discourse.org/u/AstonJ)
#### Post date: [Outubro 22, 2016, 6:00pm UTC](https://meta.discourse.org/t/twitter-github-and-normal-username-and-password-logins-not-working-after-upgrade/51854/35 "2016-10-22T18:00:51Z")
Just an update to say I followed @Falco’s advice:
> [@Falco](#):
>
> proxy\_set\_header X-Forwarded-For $proxy\_add\_x\_forwarded\_for;
> proxy\_set\_header X-Forwarded-Proto https;
and added:
`reqadd X-Forwarded-Proto:\ https if { ssl_fc }`
to the `frontend http-in` in Haproxy and it seems to be working now 👍
(I already had `option forwardfor` which is the same as `X-Forwarded-For`)
Thanks everyone! 🙂
---
### Author:  [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [Outubro 22, 2016, 6:02pm UTC](https://meta.discourse.org/t/twitter-github-and-normal-username-and-password-logins-not-working-after-upgrade/51854/36 "2016-10-22T18:02:36Z")
[Página anterior](https://meta.discourse.org/t/twitter-github-and-normal-username-and-password-logins-not-working-after-upgrade/51854.md?page=1)