`run_second_factor!` échoue lors de la tentative de promotion d'admin

Suite à Can't upgrade user to admin - unhandled server error
(Salut @Discoursenaut.) J’ai passé tout l’après-midi là-dessus. Je n’arrive toujours pas à trouver la cause du problème, mais si j’ajoute un rescue autour de la ligne 1099 (`manager.run!') l’erreur mystérieuse « Une erreur de serveur non gérée s’est produite ». Je ne trouve pas cette chaîne de caractères dans le code source.

Capturer l’erreur n’aide pas car result n’est pas défini, donc cela échoue plus tard.

J’ai essayé cela avec toutes les permutations possibles de l’utilisateur avec 2FA activé/non activé, enforce_second_factor désactivé/personnel. Étrangement, lorsque j’ai ajouté mon utilisateur aujourd’hui et que j’ai essayé d’en faire un administrateur depuis un autre compte administrateur, cela a fonctionné comme prévu, mais aucun autre administrateur ne peut faire d’autres utilisateurs des administrateurs. Ils disent que c’est un problème depuis un an. Pourrait-il y avoir un problème de base de données ?

C’est une version récente (au moins une aujourd’hui). Uniquement des plugins standard et même en mode sécurisé.

@Osama, vous avez un commentaire quelques lignes plus loin, peut-être avez-vous une idée ?

Je ne vois pas comment result peut être indéfini étant donné :

Êtes-vous absolument sûr d’être sur la toute dernière version ?

1 « J'aime »

J’ai effectué une reconstruction aujourd’hui.

Puis-je placer un journal de débogage ailleurs ?

Si vous pouviez nous fournir une reproduction minimale (comme une liste des paramètres du site et leurs valeurs), cela nous aiderait beaucoup.

Pouvez-vous rescue la méthode entière et enregistrer l’erreur ?

def run_second_factor!(action_class, action_data: nil, target_user: current_user)
  if current_user && target_user != current_user
    # Anon peut exécuter 2fa contre une autre cible, mais les utilisateurs connectés ne le devraient pas.
    # Cela doit être validé au niveau de l'appel `run_second_factor!`.
    raise "l'exécution de 2fa contre un autre utilisateur n'est pas autorisée"
  end

  action = action_class.new(guardian, request, opts: action_data, target_user: target_user)
  manager = SecondFactor::AuthManager.new(guardian, action, target_user: target_user)
  yield(manager) if block_given?
  result = manager.run!(request, params, secure_session)

  if !result.no_second_factors_enabled? && !result.second_factor_auth_completed? &&
       !result.second_factor_auth_skipped?
    # ne devrait jamais arriver, mais je veux savoir si cela se produit d'une manière ou d'une autre ! (osama)
    raise "le processus 2fa s'est terminé dans un mauvais état !"
  end

  result
+rescue => err
+  Rails.logger.error(err.full_message)
+  raise
end

Quelque chose devrait apparaître dans /logs une fois que vous aurez apporté cette modification (et rechargé les workers Unicorn), et cela devrait nous aider à comprendre quel est le problème.

2 « J'aime »

Soupir. Il semble que l’erreur dans run_second_factor! provenait de mes instructions de débogage ; provoquer des bugs en les recherchant est l’un de mes passe-temps favoris.

Started PUT "/admin/users/30591/grant_admin" for 174.50.213.142 at 2024-07-02 14:14:38 +0000
Processing by Admin::UsersController#grant_admin as */*
  Parameters: {"user_id"=>"30591"}
Completed 403 Forbidden in 6ms (Views: 0.1ms | ActiveRecord: 0.0ms | Allocations: 2263)

Je suppose que le gardien ne me permet pas de faire de l’utilisateur un administrateur pour une raison quelconque.

Mais je ne comprends toujours pas pourquoi cela échoue et pourquoi il y a une erreur « Une erreur serveur non gérée s’est produite », alors que je ne trouve cette erreur nulle part dans le code de Discourse.

Ah. Et c’est intéressant. J’ai pu changer de jay@example.com à myaddress@gmail.com, mais essayer de confirmer une adresse de myaddress+123@gmail.com génère également le message « Une erreur serveur non gérée s’est produite ». normalize_emails n’est pas défini.

Je pense que quelque chose ne va pas avec run_second_factor!, mais je n’arrive pas à comprendre quoi. J’ajoute quelques Rails.logger.warn avec quelques xxx.inspect, donc peut-être que je trouverai quelque chose.

Au mieux, je pense que quelque chose ne va pas avec le auth_manager. Il semble qu’il essaie peut-être de rediriger pour une raison quelconque ? Les utilisateurs normaux ne sont pas obligés d’avoir la 2FA, donc je ne sais pas pourquoi un utilisateur ordinaire ne pourrait pas changer son adresse e-mail. Mais j’ai essayé avec un utilisateur sans 2FA, sans codes de sauvegarde, connecté avant de cliquer sur le lien de confirmation du nouvel e-mail et après être connecté, et tout échoue avec « Une erreur serveur non gérée s’est produite ».

Cela semble lié :

L’erreur 403 est normale et attendue — l’application frontend intercepte la réponse 403 et l’interprète comme « impossible d’accorder les droits d’administrateur car l’authentification à deux facteurs est requise, naviguons vers la page d’authentification à deux facteurs ».

Ce qui n’est pas normal, c’est :

Pouvez-vous me dire où vous voyez cette erreur ? Est-ce une fenêtre pop-up dans le frontend ? Une erreur dans les logs ? Comme vous le mentionnez, je ne trouve pas ce message d’erreur dans tout l’historique du code, c’est donc très étrange.

Alors peut-être que le backend ne rend pas les éléments qui contiennent l’URL 2FA ? Mais l’erreur se produit indépendamment du fait que l’utilisateur ait activé la 2FA ou non, et indépendamment du fait que le paramètre du site force-2fa soit activé ou non. Et indépendamment du fait que l’utilisateur soit connecté avec la 2FA déjà configurée.

Exactement. J’ai essayé le mode sans échec, mais voici les plugins :

          - git clone https://github.com/discourse/docker_manager.git
          - git clone https://github.com/discourse/discourse-topic-voting.git
          - git clone https://github.com/discourse/discourse-chat-integration.git
          - git clone https://github.com/discourse/discourse-solved.git
          - git clone https://github.com/discourse/discourse-reactions.git
          - git clone https://github.com/discourse/discourse-docs.git
          - git clone https://github.com/discourse/discourse-user-notes.git

Le seul indice que j’ai trouvé est qu’il implique que le message provient de Rails lui-même. Néanmoins, je n’ai pas réussi à comprendre comment cela pourrait se produire.

Alors peut-être que quelque chose est en jeu qui déclenche « nous avons besoin de la 2FA » alors qu’en fait, la 2FA n’est pas nécessaire. Il est certainement logique qu’une erreur soit déclenchée pour la connexion 2FA alors qu’il n’y en a pas. Je suppose que c’est dans guardian ? Je n’arrive pas à trouver où mettre des instructions de débogage Rails.logger pour déboguer cela.

1 « J'aime »

C’est un coup de poker, alors je m’excuse si je dis quelque chose de totalement ridicule… mais chercher sur Google « An unhandled server error has occurred » ne fait référence qu’au code de Bitwarden, ce qui me fait penser qu’il pourrait y avoir quelque chose sur votre système local qui intercepte / perturbe votre requête. Pouvez-vous reproduire cela depuis un autre ordinateur ?

2 « J'aime »

Pouvez-vous vérifier l’onglet Réseaux dans les outils de développement de votre navigateur et voir à quoi ressemble la réponse pour la requête vers le point de terminaison grant_admin ?

Veuillez également afficher l’onglet Payload.

2 « J'aime »

image

Cela semble provenir du serveur. Je ne trouve pas cette chaîne dans la base de données (par exemple, dans le texte personnalisé) ni en recherchant dans tout /var/www/discourse.

Il n’y a pas d’onglet Payload :

image

Attendez!!! J’ai restauré la base de données sur un autre serveur et elle redirige correctement vers la page du second facteur, qui, après avoir obtenu la clé du second facteur, change immédiatement le statut d’administrateur de l’utilisateur (aucun e-mail requis ! ce que j’ignorais !).

Donc, c’est quelque chose avec… quelque chose, mais une installation propre et majoritairement standard résout le problème. Dans tous les cas, ce n’est pas (visiblement ?) un :discourse: :bug: . J’ai changé la catégorie.

L’autre explication potentielle, qui semble également tirée par les cheveux, est qu’il y a quelque chose qui ne va pas avec le modèle UserSecondFactor, car j’ai fait un UserSecondFactor.all.destroy_all;UserSecurityKey.all.destroy_all; sur mon serveur de test puisqu’il avait un nom de domaine différent. J’ai également utilisé Google Authenticator au lieu de ma Yubi key.

1 « J'aime »

Ce sujet a été automatiquement fermé 30 jours après la dernière réponse. Les nouvelles réponses ne sont plus autorisées.