DiscourseConnect Won't Let Me Log Back In

[Seal]

I must have screwed up the DiscourseConnect install using these instructions

Fortunately, the instructions include a way to directly manipulate admin settings, but apparently the one I need specifically may have changed?

The instructions say to set, SiteSetting.enable_sso=false, but:

root@hestia-app:/var/www/discourse# rails c
[1] pry(main)> SiteSettings.enable_sso=false
NoMethodError: undefined method `enable_sso=' for SiteSettings:Module
from (pry):1:in `__pry__'
[2] pry(main)> 

Anyone know what the new admin setting might be?

Thanks!

[Seal]

Ah, Discourse kindly linked the article for DiscourseConnect, and voila:

cd /var/discourse
./launcher enter app
rails c
irb > SiteSetting.enable_discourse_connect = false
irb > SiteSetting.enable_local_logins = true
irb > exit
exit

[simon]

That’s great that you found that. If you are finding references to the enable_sso setting in the WP Discourse plugin’s options pages, those references should have been changed to use the new enable_discourse_connect settings name in the most recent release of the plugin (version 2.3.0.)

If there are still references to the old settings name in the plugin’s documentation on Meta, we’ll need to get those updated to use the new settings name. I’ll double check that at the beginning of next week.

Note that while configuring DiscourseConnect, as an admin you can bypass SSO login by going to your Discourse site’s /u/admin-login page. Enter your email address into the form on the page. A one time login link will be emailed to you.

[Seal]

lol

Okay… this did give me the login page, but once I login, it logs me out and redirects me to the login page again.

The logout and redirect also happens with the /u/admin-login method. Is there some other value I should set / unset?

–edit to add–

Is there a way I can verify the admin setting values from the rails c cli?

[simon]

@Seal

Is there a way I can verify the admin setting values from the rails c cli?

On Discourse, you need the following settings:

• enable_discourse_connect
• discourse_connect_url (should be set to your WordPress site’s homepage)
• discourse_connect_secret (make sure it’s value matches what you have entered in the DiscourseConnect Secret Key setting on your WordPress site)

You should probably also enable the verbose_discourse_connect_logging site setting on Discourse. With that setting enabled you may get some useful details about the cause of the issue in your Discourse error logs.

On WordPress, make sure you’ve filled in the DiscourseConnect Secret Key setting. The only other setting that has to be enabled on WordPress is the Enable DiscourseConnect Provider setting.

[Seal]

@simon thanks a million for the verbose_discourse_connect_logging tip!

Okay, so enable_discourse_connect is false and enable_local_logins is true

Maybe someone knows what is going on here?

Let’s click the admin login email link

Started GET "/session/email-login/5356b2413338852f25d4382e34fb53a6" for {my.ip.address} at 2021-08-07 02:33:43 +0000
Processing by SessionController#email_login_info as HTML
  Parameters: {"token"=>"5356b2413338852f25d4382e34fb53a6"}
  Rendered default/empty.html.erb within layouts/application (Duration: 0.1ms | Allocations: 11)
  Rendered layout layouts/application.html.erb (Duration: 41.1ms | Allocations: 8102)
Completed 200 OK in 66ms (Views: 43.4ms | ActiveRecord: 0.0ms | Allocations: 12210)
Started GET "/session/email-login/5356b2413338852f25d4382e34fb53a6.json" for {my.ip.address} at 2021-08-07 02:33:48 +0000
Processing by SessionController#email_login_info as JSON
  Parameters: {"token"=>"5356b2413338852f25d4382e34fb53a6"}
Completed 200 OK in 25ms (Views: 0.3ms | ActiveRecord: 0.0ms | Allocations: 4548)

Okay, let’s click the login link on the Discourse Install

Started GET "/session/csrf" for {my.ip.address} at 2021-08-07 02:33:56 +0000
Processing by SessionController#csrf as JSON
Completed 200 OK in 2ms (Views: 0.3ms | Allocations: 308)

Started POST "/session/email-login/5356b2413338852f25d4382e34fb53a6" for {my.ip.address} at 2021-08-07 02:33:57 +0000
Processing by SessionController#email_login as */*
  Parameters: {"second_factor_method"=>"1", "timezone"=>"America/Denver", "token"=>"5356b2413338852f25d4382e34fb53a6"}
Completed 200 OK in 231ms (Views: 0.3ms | ActiveRecord: 0.0ms | Allocations: 24272)

Something goes sideways here

Started GET "/" for {my.ip.address} at 2021-08-07 02:33:58 +0000
Processing by ListController#latest as HTML
Redirected to http://my.discourse.install/login
Filter chain halted as :redirect_to_login_if_required rendered or redirected
Completed 302 Found in 2ms (ActiveRecord: 0.0ms | Allocations: 613)

Now we just render the login screen which it does just fine

Started GET "/login" for {my.ip.address} at 2021-08-07 02:33:59 +0000
Processing by StaticController#show as HTML
  Parameters: {"id"=>"login"}
  Rendered static/login.html.erb within layouts/application (Duration: 38.2ms | Allocations: 1520)
  Rendered layout layouts/application.html.erb (Duration: 103.4ms | Allocations: 12203)
Completed 200 OK in 130ms (Views: 105.7ms | ActiveRecord: 0.0ms | Allocations: 16261)
Started GET "/login.html" for {my.ip.address} at 2021-08-07 02:34:04 +0000
Processing by StaticController#show as HTML
  Parameters: {"id"=>"login"}
  Rendered static/login.html.erb (Duration: 22.0ms | Allocations: 1352)
Completed 200 OK in 25ms (Views: 23.0ms | Allocations: 1970)

[Seal]

Also, does anyone know if there is a command I can use in the $rails c cli that will dump all the admin setting / value pairs? I think I could just reset all the DiscourseConnect stuff and start over. Or hell maybe there is a cli command that will just reset all the admin settings to initial state?

—edit to add—

lol, I just found SiteSetting.all , now that is brutal dump of information. Does it have filters?

—edit to add—

Found this little gem in another post:

puts SiteSetting.all.map {|s| "#{s.name}: #{s.value}" } .join "\n"

…and I reset everything remotely related to DiscourseConnect. Still get the weird login redirect.

enable_bookmarks_with_reminders: t
meta_category_id: 2
staff_category_id: 3
lounge_category_id: 4
default_theme_id: 1
tos_topic_id: 4
guidelines_topic_id: 5
privacy_topic_id: 6
welcome_topic_id: 7
lounge_welcome_topic_id: 8
admin_quick_start_topic_id: 9
push_api_secret_key: {redacted}
send_welcome_message: f
has_login_hint: f
global_notice: 
default_trust_level: 1
default_email_digest_frequency: 1440
bootstrap_mode_enabled: t
title: {redacted}
site_description: {redacted}
short_site_description: {redacted}
login_required: t
must_approve_users: t
contact_email: {redacted}
contact_url: {redacted}
site_contact_username: system
company_name: {redacted}
base_font: oxanium
heading_font: system
logo: 3
logo_small: 4
force_https: t
allow_user_locale: t
categories_topics: 25
suggested_topics: 7
share_links: email
share_quote_buttons: email
default_dark_mode_color_scheme_id: 1
topics_per_period_in_top_summary: 25
unicode_usernames: f
enable_names: f
enable_user_directory: f
allow_anonymous_posting: t
anonymous_posting_min_trust_level: 0
allow_uncategorized_topics: f
show_copy_button_on_codeblocks: t
max_image_megapixels: 150
max_image_size_kb: 10000
max_attachment_size_kb: 10000
clean_up_uploads: t
external_system_avatars_enabled: f
vapid_public_key: {redacted}
vapid_private_key: {redacted}
vapid_public_key_bytes: {redacted}
vapid_base_url: {redacted}
enable_local_logins: t
enable_discourse_connect: f
pop3_polling_username: {redacted}
enable_discourse_connect_provider: f
discourse_connect_allows_all_return_paths: f
discourse_connect_url: 
discourse_connect_secret: 

[Seal]

So I try to add a new account, and I get the following error message:

We cannot detect if your account was created, please ensure you have cookies enabled.

Whaaaat? Maybe I should just re-install???

—edit to add—

I did get the signup verify email, it worked and when I tried to login as a new user I got:

A moderator must manually approve your new account before you can access this forum. You’ll get an email when your account is approved!

lol…

—edit to add—

Just wanted to say I do like the complexity of discourse. It is am amazing piece of software. The only forum that really comes close is XF. Years ago when [unknown] was still the main dev for SimpleMachines, that was a beautiful thing as well, but that era is long over. Thanks to all the devs. This is a great, elegant machine you all have crafted.

[Seal]

The real error seems to be Can’t verify CSRF token authenticity. The answer was in this thread: Can't Login to Discourse - CSRF Token Authenticity

I added the following to my apache2.conf file:

RequestHeader set X-Forwarded-Proto https

From the error log:

Started POST "/session" for {my.ip} at 2021-08-07 11:45:54 +0000
Processing by SessionController#create as */*
  Parameters: {"login"=>"{me}", "password"=>"[FILTERED]", "second_factor_method"=>"1", "timezone"=>"America/Denver"}
Can't verify CSRF token authenticity.
  Rendered text template (Duration: 0.0ms | Allocations: 1)
Filter chain halted as :verify_authenticity_token rendered or redirected
Completed 403 Forbidden in 13ms (Views: 1.5ms | ActiveRecord: 0.0ms | Allocations: 898)

[angus (Angus McLeod)]

@Seal

The real error seems to be Can’t verify CSRF token authenticity. The answer was in this thread: Can’t Login to Discourse - CSRF Token Authenticity

Glad you found the cause. I’m curious, how have you set up your Discourse? I’m guessing you’re not using the standard docker install?

@simon

If there are still references to the old settings name in the plugin’s documentation on Meta, we’ll need to get those updated to use the new settings name. I’ll double check that at the beginning of next week.

I’ve updated the references in WP Discourse plugin installation and setup

[Seal]

I did use Docker, but I reverse proxied it behind apache2 so that I could run it behind Hestia Control Panel as a virtual host. I had set up Hestia with Apache2 instead of Nginx… so that’s why I used Apache2.

If you look at the end of this thread you can see my setup.