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
192.30.253.113 github.com
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/ssovia HTTPS, sendingCookie: _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=xxxxxxvia HTTPS, sendingCookie: _forum_session=VXdwith 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/ssoagain.
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.
2 Likes
And you use the socketed template?
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).
2 Likes
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?
2 Likes
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 
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.)
3 Likes
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.
3 Likes
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 (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 
(I already had option forwardfor which is the same as X-Forwarded-For)
Thanks everyone! 
3 Likes