Si vous avez conservé votre session, vous ne rencontrerez aucun problème. Cependant, si vous essayez de vous connecter maintenant, en cliquant sur « Se connecter », l’URL change pour : /auth/failure?message=csrf_detected et nous obtenons le message d’erreur : « L’autorisation a expiré, ou vous avez changé de navigateur. Veuillez réessayer. ».
Quelqu’un sait-il s’il y a eu un changement récent qui pourrait expliquer cette situation ?
Une question en passant : existe-t-il un moyen de revenir à une version précédente ? J’ai fait des recherches et le consensus est de désactiver les plugins (ou le plugin spécifique en cause). Cependant, je ne peux pas désactiver celui-ci, car c’est ainsi que mes utilisateurs se connectent à la plateforme
Ce n’est pas vraiment pris en charge, mais si vous avez une sauvegarde, vous pouvez supprimer le répertoire de données PostgreSQL, ajouter un commit dans la ligne de version du fichier app.yml, reconstruire l’application, puis restaurer la sauvegarde.
Ouais, j’ai fait une sauvegarde et j’essaie de reconstruire en utilisant le SHA de la version que j’avais, car elle fonctionne de manière incertaine.
Parallèlement, j’ai toujours la version la plus récente et stable pour voir si nous pouvons la réparer d’une manière ou d’une autre.
Je ne sais pas si @david a des conseils comme suggéré par @codinghorror, mais je suis prêt à tout essayer puisque mes utilisateurs sont bloqués (sauf s’ils ont conservé leur session).
Mise à jour rapide : J’ai essayé d’utiliser une version de sauvegarde avec une capture d’état de la machine à ce moment-là (avant la mise à niveau). Cliquer sur « Se connecter » recharge simplement la page principale deux fois. J’ai aussi essayé de reconstruire avec le SHA exact du commit que j’avais à l’époque, sans succès : erreur Rake sur la base de données.
J’ai cherché d’autres rapports concernant le problème LDAP, mais il n’en semble exister aucun. Cela pourrait-il être causé par une source externe ?
Problème résolu, la cause racine a été identifiée : elle n’est pas liée à Discourse (désolé les amis !). Le problème venait du fait que le certificat a été mis à jour et servi via un HAP. Auparavant, nous n’utilisions pas de HAP et Discourse le servait lui-même. Nous avons oublié ce détail, ce qui a entraîné cette erreur CORS.
Leçons tirées :
Revenir en arrière sur Discourse n’est pas une option ; mieux vaut avoir une sauvegarde complète de la machine (ce qui était le cas, heureusement).
Je dois encore comprendre pourquoi il était si difficile de reconstruire avec un SHA spécifique en suivant les instructions que j’ai lues ici ; je n’ai pas réussi à le faire.
Il vaut mieux toujours servir les certificats depuis le HAP, mais ne pas oublier ce détail. (Note pour les autres : il est nécessaire d’ajouter le drapeau 'set-header X-Forwarded-Proto https' car Discourse dispose de son propre NGINX, et c’est là que l’échec se produisait).
Le fait que personne n’ait signalé le même problème (même en considérant qu’il s’agit d’un cas limite puisque le plugin n’est pas officiel) indiquait cette direction (Communauté comme prévu :P).
Le problème ne s’est manifesté que tardivement (au point que nous ne nous souvenions plus du changement de certificat) en raison de la reconstruction déclenchée par la mise à jour, moment où l’échec s’est produit.
