Discourse lost the ability to login for all accounts

Support
1

I’m using Digital Ocean droplet to host Discourse(last version) with Nginx+Let’s Encrypt SSL in front.

Yesterday when I was working to enable LinkedIn OAuth login. I’d enabled FORCE_HTTPS to try if it will make OAuth login work but I lost the ability to login from to all accounts. After I’d tried many advice’s from the community nothing worked. So I restored my previous droplet snapshot to my working copy.

Then I started by enabling FORCE_HTTPS to test if anything will broke. Everything worked fine. So continued adding the plugins without any problem.

But still I had problem to make login with LinkedIn and Google to work. Following one advice to change Google client callback setup to http vs. https, and its worked. So I did the same for LinkedIn and I was keep trying.

To save myself from login and logout I was trying to sign-up with Google/LinkedIn/Twitter just to see the coming window if its error or not without creating the account (by closing the window of authentication) just After 3-4 times trying I noticed that I lost the complete login to Discourse from all the accounts!.

I’d tried the site.com/users/admin-login and sent the email to 2 different Admin accounts but wasn’t useful. Discourse acting like everything is okay but instead of redirecting the user to its logged in page, it was always the same, the page where expecting you to login or to signup.

I’d tried to reset my admin password from the login window. Its working fine. The email sent to me to reset a new password. The link worked fine and Discourse asked me to enter my new password, accepted successfully and informed that I’m logged in and redirected me to page which i’m not logged in again.

Just for another try. I did created a new user, I’ve got the email to confirm and Discourse accepted my login but again redirect to not logged in page!. I even received the welcome email :slight_smile: .

I did ./launcher rebuild app and tried again. Nothing changed.

So it’s seems like there is something serious here. I’d tried to detail my steps to got this problem thinking that it may help the developers to guess its origin. I had no major changes to make Discourse lose control. I’m afraid that it may happen to any running Discourse instance and need immediate investigation.

I hope there is a solution for what I’m facing and I’ll be happy if anyone could share it in here!

If any question needed regarding my system with this issue, please ask now before I restore my droplet again :eyes:

2

Can you try disabling force_https for now?

My guess is that your problem is similar to

https://meta.discourse.org/t/users-unable-to-login-after-container-rebuild/51709

1 Like
3

Thank you @tgxworld. Because I’m not able to login at all there was no way to do it from the site. So I’d tried to follow the instruction on how to do it from console (as I’d tried yesterday when I’d faced the same problem) but I’m getting a fatal error again as seen here:

4

Try this:

/var/discourse/launcher enter app
rails c
SiteSetting.force_https = false
4 Likes
5

Many thanks @fefrei. You saved my day!. I announce you a man of the DAY :tada:
It’s Worked :slight_smile:

6

Just a brief explanation on why that worked versus the prior attempt.

The prior attempt you tried using bundle exec rails c which was designed for development environments, not the official docker installations. With the official docker installations, you don’t need to invoke it through bundle exec (took me a moment to figure out the difference here)

3 Likes
7

Its great to understand the reason @cpradio. It was a question in my head that you answered. Thank you very much. :sparkles:

The problem in here, sometimes people do not mention/aware what environment they are giving advice to. Maybe a lot of people like me, creating a lot of unnecessary problems trying to fix one because of that.

8

As we used to do ./launcher rebuild app at every change so I did it too. But after a thought, I wasn’t sure if that was necessary this time?

Not urgent but it would be very much helpful. Any other parameters we could modify this way (it would be very helpful for future reference) ?

9

A rebuild is necessary when you modified app.yml (with a few exceptions where a restart is enough) or want to update the base image.

With the SiteSetting object on the rails console, you can update everything listed in the admin UI under site settings, plus a few secret bonus settings :slight_smile:

3 Likes
10

Just to add to @fefrei’s explanation, rebuild is unnecessary for this round because you weren’t changing the app.yml, you were invoking Discourse’s internal API which updated the database and thus the next time you attempted to access your Discourse instance, it was able to read force_https as false.

Every bit of the Discourse application runs off of its own internal UI, so every action you can perform in your browser, there are commands you can run to reproduce those exact actions. In times where you lock yourself out, it is really helpful.

3 Likes
11

That’s great info Felix. Where I could find the SiteSetting object elements lists (and its options if possible) without digging into the source code? :blush:

12

There shouldn’t really be a reason to do this – almost all site settings can be configured from the web UI (and if you need to configure them from the console, just replaces spaces in their name with _), and the others aren’t really meant to be tweaked :wink:

1 Like
13

Personally, I much prefer this “completely broken” behavior, over “super subtly broken” behavior we had before.

In the past, if you had this enabled, images would be broken in your emails among other weird and wonderful edge cases of broken.

Not entirely against a magic detection thing, but want to watch this for a bit longer.

5 Likes
14

This topic was automatically closed after 2788 days. New replies are no longer allowed.