DiscourseConnect ne me permet pas de me reconnecter

[Seal]

J’ai dû faire une erreur lors de l’installation de DiscourseConnect en suivant ces instructions.

Heureusement, les instructions prévoient une méthode pour modifier directement les paramètres d’administration, mais apparemment, celui dont j’ai besoin a peut-être changé ?

Les instructions indiquent de définir SiteSetting.enable_sso=false, mais :

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

Quelqu’un sait quelle pourrait être le nouveau paramètre d’administration ?

Merci !

[Seal]

Ah, Discourse a aimablement lié l’article pour DiscourseConnect, et hop :

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

[simon]

C’est formidable que vous ayez trouvé cela. Si vous rencontrez des références au paramètre enable_sso dans les pages d’options du plugin WP Discourse, ces références auraient dû être mises à jour pour utiliser le nouveau nom de paramètre enable_discourse_connect dans la version la plus récente du plugin (version 2.3.0).

Si des références à l’ancien nom de paramètre persistent dans la documentation du plugin sur Meta, nous devrons les mettre à jour pour utiliser le nouveau nom. Je vérifierai cela dès le début de la semaine prochaine.

Notez que lors de la configuration de DiscourseConnect, en tant qu’administrateur, vous pouvez contourner la connexion SSO en accédant à la page /u/admin-login de votre site Discourse. Entrez votre adresse e-mail dans le formulaire de la page. Un lien de connexion à usage unique vous sera envoyé par e-mail.

[Seal]

lol

Bon… cela m’a bien affiché la page de connexion, mais une fois connecté, je suis déconnecté et redirigé vers la page de connexion à nouveau.

La déconnexion et la redirection se produisent également avec la méthode /u/admin-login. Y a-t-il une autre valeur que je devrais définir ou annuler ?

–edit pour ajouter–

Existe-t-il un moyen de vérifier les valeurs des paramètres administrateur depuis le CLI de rails c ?

[simon]

@Seal

Existe-t-il un moyen de vérifier les valeurs des paramètres d’administration depuis la ligne de commande Rails (rails c) ?

Sur Discourse, vous devez configurer les paramètres suivants :

• enable_discourse_connect
• discourse_connect_url (doit être défini sur la page d’accueil de votre site WordPress)
• discourse_connect_secret (assurez-vous que sa valeur correspond à celle entrée dans le paramètre « DiscourseConnect Secret Key » de votre site WordPress)

Il est également probable que vous deviez activer le paramètre de site verbose_discourse_connect_logging sur Discourse. Une fois ce paramètre activé, vous pourrez obtenir des détails utiles sur la cause du problème dans vos journaux d’erreurs Discourse.

Sur WordPress, assurez-vous d’avoir rempli le paramètre « DiscourseConnect Secret Key ». Le seul autre paramètre devant être activé sur WordPress est l’option « Enable DiscourseConnect Provider ».

[Seal]

@simon merci infiniment pour l’astuce verbose_discourse_connect_logging !

Donc, enable_discourse_connect est à false et enable_local_logins est à true.

Quelqu’un saurait-il ce qui se passe ici ?

Cliquons sur le lien de connexion par e-mail administrateur

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)

Ok, cliquons sur le lien de connexion sur l’installation de Discourse

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)

Quelque chose se passe mal ici

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)

Maintenant, nous affichons simplement l’écran de connexion, ce qui se passe très bien

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]

D’ailleurs, quelqu’un sait-il s’il existe une commande utilisable dans le CLI $rails c qui permet d’exporter toutes les paires de paramètres/valeurs d’administration ? Je pensais pouvoir simplement réinitialiser tout ce qui concerne DiscourseConnect et repartir de zéro. Ou alors, peut-être existe-t-il une commande CLI qui réinitialise directement tous les paramètres d’administration à leur état initial ?

— Édition ajoutée —

lol, je viens de trouver SiteSetting.all, c’est un dump d’informations assez brutal. Est-ce qu’il prend des filtres ?

— Édition ajoutée —

J’ai trouvé ce petit bijou dans un autre post :

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

…et j’ai réinitialisé tout ce qui était même vaguement lié à DiscourseConnect. Je rencontre toujours cette redirection étrange lors de la connexion.

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]

Alors, j’essaie d’ajouter un nouveau compte et j’obtiens le message d’erreur suivant :

Nous ne pouvons pas détecter si votre compte a été créé ; veuillez vous assurer que les cookies sont activés.

Quoi ? Peut-être que je devrais simplement réinstaller ???

—Edit pour ajouter—

J’ai bien reçu l’e-mail de vérification d’inscription, cela a fonctionné, et lorsque j’ai essayé de me connecter en tant que nouvel utilisateur, j’ai obtenu :

Un modérateur doit approuver manuellement votre nouveau compte avant que vous puissiez accéder à ce forum. Vous recevrez un e-mail lorsque votre compte sera approuvé !

lol…

—Edit pour ajouter—

Je voulais juste dire que j’apprécie la complexité de Discourse. C’est un logiciel incroyable. Le seul forum qui s’en approche vraiment est XF. Il y a des années, lorsque [unknown] était encore le développeur principal de Simple Machines, c’était aussi une chose magnifique, mais cette époque est révolue depuis longtemps. Merci à tous les développeurs. C’est une machine formidable et élégante que vous avez tous façonnée.

[Seal]

La véritable erreur semble être Impossible de vérifier l’authenticité du jeton CSRF. La réponse se trouvait dans ce fil de discussion : Can't Login to Discourse - CSRF Token Authenticity

J’ai ajouté la ligne suivante à mon fichier apache2.conf :

RequestHeader set X-Forwarded-Proto https

Voici ce que contient le journal des erreurs :

Démarrage de la requête POST "/session" depuis {my.ip} le 2021-08-07 11:45:54 +0000
Traitement par SessionController#create en */*
  Paramètres : {"login" => "{me}", "password" => "[FILTRÉ]", "second_factor_method" => "1", "timezone" => "America/Denver"}
Impossible de vérifier l'authenticité du jeton CSRF.
  Rendu du modèle texte (Durée : 0,0 ms | Allocations : 1)
La chaîne de filtres s'est arrêtée car :verify_authenticity_token a rendu ou redirigé
Terminé avec 403 Forbidden en 13 ms (Vues : 1,5 ms | ActiveRecord : 0,0 ms | Allocations : 898)

[angus (Angus McLeod)]

@Seal

La véritable erreur semble être Impossible de vérifier l’authenticité du jeton CSRF. La réponse se trouvait dans ce fil : Impossible de se connecter à Discourse - Authenticité du jeton CSRF

Ravi que vous ayez trouvé la cause. Je suis curieux, comment avez-vous configuré votre Discourse ? Je suppose que vous n’utilisez pas l’installation Docker standard ?

@simon

S’il reste des références à l’ancien nom de paramètre dans la documentation du plugin sur Meta, nous devrons les mettre à jour pour utiliser le nouveau nom de paramètre. Je vérifierai cela au début de la semaine prochaine.

J’ai mis à jour les références sur Install and configure the WP Discourse Wordpress plugin for Discourse

[Seal]

J’ai bien utilisé Docker, mais je l’ai placé derrière un reverse proxy Apache2 afin de pouvoir l’exécuter derrière le panneau de contrôle Hestia en tant que serveur virtuel. J’avais configuré Hestia avec Apache2 plutôt qu’avec Nginx… c’est pourquoi j’ai utilisé Apache2.

Si vous consultez la fin de ce fil de discussion, vous pourrez voir ma configuration.

[system (system) A fermé ce sujet ()]

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.