Cependant, après avoir cliqué sur le bouton Autoriser, l’utilisateur est redirigé et rencontre ce message sur notre forum :
et l’erreur en haut de ce sujet apparaît dans les journaux d’administration.
J’ai l’impression d’avoir lu et essayé toutes les solutions pour corriger cela, mais cela continue de se produire. J’ai vérifié que l’ID client et le secret Discord des paramètres du site sont corrects.
J’ai également vérifié que l’URI était de la bonne syntaxe (basé sur quelques sujets connexes que j’ai vus) :
Je pense (??) avoir réduit le problème à un problème nginx et/ou de mise en cache ? Y a-t-il des éléments spécifiques à l’authentification ou spécifiques au CSRF qui devraient être définis dans discourse.conf et que nous pourrions manquer ?
@merefield, @david, @sam - désolé pour les pings, mais je vois vos noms dans de nombreuses discussions antérieures liées au csrf. Avez-vous des recommandations à ce sujet ? Avec l’authentification Discord intégrée à Discourse, je ne sais pas ce qui pourrait causer cela.
Je n’arrive toujours pas à trouver un schéma. Parfois, cela fonctionne et me connecte correctement, mais d’autres fois, je suis confronté à la page csrf.
Pour le moment, je suspecte le dernier contrôle de condition dans verified_request?.
Existe-t-il des moyens de vérifier facilement si (valid_request_origin? && any_authenticity_token_valid?) renvoie true ?
Je m’excuse pour le manque d’informations déboguables, mais je pense avoir (péniblement) trouvé (du moins ce que je crois être) le problème. Je ne suis toujours pas sûr de la solution, alors lisez la suite
Les images ci-dessous montrent une instance consécutive où j’ai pu lier mon compte avec succès, j’ai actualisé/réessayé et j’ai rencontré la page « csrf detected » sans succès. J’étais dans une fenêtre de navigation privée et je n’ai littéralement rien fait/changé entre la connexion réussie et l’échec du csrf. Voici ce que j’ai trouvé :
Cette première image montre que le cookie _forum_session correspond dans les en-têtes des requêtes 1 et 2, ce qui a entraîné une connexion réussie.
Cependant, après avoir rechargé la page et réessayé (et échoué à me connecter), vous pouvez voir que ma recherche sur le côté gauche n’affiche qu’une seule occurrence du cookie _forum_session dans un en-tête de requête lorsqu’elle a entraîné un échec.
En bref : je suis presque sûr que le problème vient du cookie forum_session dans l’en-tête de la requête discord?reconnect, puis que l’en-tête de la requête callback? suivante ne correspond pas. Qu’est-ce qui pourrait les faire être différents ?
Ok, je pense qu’on s’approche.\n\nDonc sur cette image ci-dessous, vous pouvez voir une requête POST de mise à jour se produire directement après la requête POST discord?reconnect.\n
\n\nSi je vérifie une instance de connexion réussie (ci-dessous), vous pouvez voir que la mise à jour ne se produit que avant la requête POST discord?reconnect.\n\n
\n\nCela permet au cookie _forum_session de correspondre et de connecter le compte avec succès sans le problème csrf.\n\n\nComment puis-je empêcher cette mise à jour de se produire après que l’utilisateur ait commencé le processus de connexion ?
@FerrariFlunker désolé pour la réponse lente, mais je n’ai pas eu la chance de regarder ça, ce serait formidable si l’équipe principale pouvait le faire.
si cela peut vous consoler, je peux reproduire, je crois, la même erreur :
Rencontrez-vous cette erreur dans votre propre environnement ? Je pense que de toute façon, cette erreur doit être examinée par l’équipe principale. Cela fait plus de 2 semaines que je débogue cela et je n’ai toujours pas trouvé de réponse
Bien vu ! Ce genre de condition de concurrence pourrait certainement causer les problèmes que vous rencontrez.
Cela dit, nous n’avons eu aucun autre rapport de ce problème, il semble donc que ce soit quelque chose de spécifique à votre site/configuration. Quels plugins avez-vous installés sur le site ? Pouvez-vous ouvrir l’appel « update » et voir quelle charge utile est envoyée ?
Après avoir examiné les appels de mise à jour, je pense que vous avez raison. Voici quelques captures d’écran de requêtes de « mise à jour » confirmées qui ont provoqué des échecs csrf.
Je vois un schéma impliquant cdn Qu’est-ce qui pourrait être mal configuré avec cela ? Faites-moi savoir si vous avez toujours besoin d’une liste de nos plugins, je pensais juste vous épargner cette réponse avec +1 image
avec l’un de nos plugins !
Après avoir désactivé le plugin, effectué des tests supplémentaires et lancé avec succès la fonctionnalité associée à la communauté… Je pense pouvoir dire avec confiance que nous avons trouvé le coupable.
Rétrospectivement, il est logique que ce soit le coupable : le plugin est toujours marqué comme expérimental et n’est pas destiné aux sites de production.
Comme je suis à plus de 3 semaines de diagnostic de ce problème et que je dois me remettre au travail sur les autres projets de notre communauté , je ne pourrai malheureusement pas aider à trouver la solution pour le plugin discourse-chat.
Si quelqu’un finit par proposer une solution pour le plugin, nous envisagerons (très probablement ) de réactiver le plugin sur notre site, mais pour l’instant, nous avons besoin d’une fonctionnalité de connexion de compte associée stable.
Merci encore à tous ceux qui ont aidé au diagnostic !
Je viens de créer une PR pour une correction dans le cœur de Discourse :
La raison pour laquelle cela a été corrigé après la suppression du plugin de chat est que le chat utilise beaucoup cette API ‘PresenceChannel’, et donc le problème est beaucoup plus susceptible de se produire. Je ne pense pas que des modifications soient nécessaires dans le chat.
Cela devrait-il résoudre le même problème avec les connexions Google ? Mes utilisateurs sur une de mes instances où nous testions le plugin de chat l’ont adoré, mais cela a cassé les connexions Google avec la même erreur que les connexions Discord.