DiscourseConnect lässt mich nicht wieder rein

[Seal]

Ich habe die DiscourseConnect-Installation wohl mit diesen Anweisungen vermasselt.

Glücklicherweise enthalten die Anweisungen eine Möglichkeit, Admin-Einstellungen direkt zu ändern, aber anscheinend hat sich die, die ich brauche, geändert?

Laut den Anweisungen soll man SiteSetting.enable_sso=false setzen, aber:

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

Weiß jemand, wie die neue Admin-Einstellung heißt?

Danke!

[Seal]

Ah, Discourse hat den Artikel für DiscourseConnect freundlich verlinkt, und siehe da:

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

[simon]

Das ist großartig, dass du das gefunden hast. Wenn du im WP Discourse-Plugin in den Optionen-Seiten noch auf die enable_sso-Einstellung verweist, sollten diese Verweise in der neuesten Version des Plugins (Version 2.3.0) bereits auf den neuen Namen enable_discourse_connect aktualisiert worden sein.

Sollten in der Plugin-Dokumentation auf Meta noch Verweise auf den alten Einstellungsname vorhanden sein, müssen wir diese auf den neuen Namen aktualisieren. Ich werde das Anfang nächster Woche noch einmal überprüfen.

Hinweis: Beim Einrichten von DiscourseConnect kannst du dich als Administrator umgehen, indem du die Seite /u/admin-login deiner Discourse-Website aufrufst. Gib deine E-Mail-Adresse in das Formular auf der Seite ein. Dir wird ein einmaliger Login-Link per E-Mail zugesendet.

[Seal]

lol

Okay… das hat mir zwar die Anmeldeseite angezeigt, aber sobald ich mich anmeldet, werde ich wieder ausgeloggt und erneut zur Anmeldeseite weitergeleitet.

Das Ausloggen und die Weiterleitung treten auch bei der Methode /u/admin-login auf. Sollte ich einen anderen Wert setzen bzw. entfernen?

–Edit–

Gibt es eine Möglichkeit, die Admin-Einstellungswerte über die Rails-CLI (rails c) zu überprüfen?

[simon]

@Seal

Gibt es eine Möglichkeit, die Admin-Einstellungswerte über die Rails C-CLI zu überprüfen?

In Discourse benötigen Sie folgende Einstellungen:

• enable_discourse_connect
• discourse_connect_url (sollte auf die Startseite Ihrer WordPress-Site eingestellt sein)
• discourse_connect_secret (stellen Sie sicher, dass der Wert mit dem übereinstimmt, was Sie in der Einstellung DiscourseConnect-Geheimschlüssel auf Ihrer WordPress-Site eingegeben haben)

Sie sollten wahrscheinlich auch die Site-Einstellung verbose_discourse_connect_logging in Discourse aktivieren. Mit dieser aktivierten Einstellung erhalten Sie möglicherweise einige nützliche Details zur Ursache des Problems in Ihren Discourse-Fehlerprotokollen.

Stellen Sie in WordPress sicher, dass Sie die Einstellung DiscourseConnect-Geheimschlüssel ausgefüllt haben. Die einzige andere Einstellung, die in WordPress aktiviert sein muss, ist die Einstellung DiscourseConnect-Anbieter aktivieren.

[Seal]

@simon vielen Dank für den Tipp mit verbose_discourse_connect_logging!

Okay, also ist enable_discourse_connect auf false und enable_local_logins auf true gesetzt.

Vielleicht weiß jemand, was hier los ist?

Lass uns auf den Admin-Login-E-Mail-Link klicken

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, lass uns auf den Login-Link der Discourse-Installation klicken

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)

Hier läuft etwas schief

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)

Jetzt wird einfach der Login-Bildschirm gerendert, was auch problemlos funktioniert

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]

Außerdem: Weiß jemand, ob es einen Befehl in der $rails c CLI gibt, mit dem ich alle Admin-Einstellungen und ihre Werte ausgeben kann? Ich könnte einfach alles DiscourseConnect-Related zurücksetzen und von vorne beginnen. Oder vielleicht gibt es ja sogar einen CLI-Befehl, der alle Admin-Einstellungen auf den Anfangszustand zurücksetzt?

—Edit hinzugefügt—

lol, ich habe gerade SiteSetting.all gefunden – das ist eine ziemlich brutale Ausgabe von Informationen. Gibt es dafür Filter?

—Edit hinzugefügt—

Ich habe diese kleine Perle in einem anderen Beitrag gefunden:

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

…und ich habe alles zurückgesetzt, was auch nur entfernt mit DiscourseConnect zu tun hat. Immer noch dieser seltsame 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]

Also, ich versuche, ein neues Konto hinzuzufügen, und erhalte folgende Fehlermeldung:

Wir können nicht feststellen, ob Ihr Konto erstellt wurde. Stellen Sie bitte sicher, dass Cookies aktiviert sind.

Was? Vielleicht sollte ich einfach neu installieren???

—Edit hinzugefügt—

Ich habe die Bestätigungs-E-Mail zur Registrierung erhalten, es hat funktioniert, und als ich versuchte, mich als neuer Benutzer anzumelden, bekam ich:

Ein Moderator muss Ihr neues Konto manuell genehmigen, bevor Sie auf dieses Forum zugreifen können. Sie erhalten eine E-Mail, sobald Ihr Konto genehmigt wurde!

lol…

—Edit hinzugefügt—

Ich wollte nur sagen, dass mir die Komplexität von Discourse gefällt. Es ist ein erstaunliches Stück Software. Das einzige Forum, das wirklich in die Nähe kommt, ist XF. Vor Jahren, als [unknown] noch der Hauptentwickler für SimpleMachines war, war das auch etwas Schönes, aber diese Ära ist längst vorbei. Danke an alle Entwickler. Das ist eine großartige, elegante Maschine, die ihr alle erschaffen habt.

[Seal]

Der eigentliche Fehler scheint zu lauten: CSRF-Token-Autorität kann nicht verifiziert werden. Die Antwort befindet sich in diesem Thread: Can't Login to Discourse - CSRF Token Authenticity

Ich habe Folgendes zu meiner apache2.conf-Datei hinzugefügt:

RequestHeader set X-Forwarded-Proto https

Aus dem Fehlerprotokoll:

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

Der eigentliche Fehler scheint zu sein: CSRF-Token-Authentizität kann nicht verifiziert werden. Die Antwort befindet sich in diesem Thread: Kein Login bei Discourse möglich – CSRF-Token-Authentizität

Schön, dass du die Ursache gefunden hast. Ich bin neugierig: Wie hast du Discourse eingerichtet? Ich vermute, du verwendest nicht die Standard-Docker-Installation?

@simon

Wenn in der Dokumentation des Plugins auf Meta noch Verweise auf den alten Einstellungsnamen enthalten sind, müssen diese auf den neuen Einstellungsnamen aktualisiert werden. Ich werde das Anfang nächster Woche noch einmal überprüfen.

Ich habe die Verweise in Install and configure the WP Discourse Wordpress plugin for Discourse aktualisiert

[Seal]

Ich habe Docker verwendet, es jedoch hinter Apache2 als Reverse-Proxy konfiguriert, damit ich es als virtuellen Host im Hestia Control Panel betreiben konnte. Ich hatte Hestia mit Apache2 statt Nginx eingerichtet … deshalb habe ich Apache2 verwendet.

Wenn du das Ende dieses Threads ansiehst, kannst du meine Konfiguration einsehen.