Après une reconstruction aujourd’hui avec la version 3.3.3 (la dernière version stable publiée il y a quelques jours), le SSO a cessé de fonctionner. Les utilisateurs déjà connectés fonctionnent toujours pour le moment, mais les nouvelles sessions terminent le flux SSO avec l’erreur :
La connexion au compte a expiré, veuillez réessayer de vous connecter.
L’activation de la journalisation détaillée de Discourse Connect (verbose discourse connect logging) montre :
Journal SSO détaillé : Le nonce est incorrect, a été généré dans une session de navigateur différente ou a expiré
Cependant, rien dans notre flux SSO n’a changé ces dernières années. Les horloges des serveurs sont synchronisées.
D’autre part, nous avons très récemment mis à jour vers la version 3.3.3 (depuis la 3.3.2) qui contient des corrections de sécurité liées à Discourse Connect qui pourraient être pertinentes.
Peu probable que ce soit pertinent, mais la reconstruction visait à activer un CDN. Mais j’ai déjà annulé toutes ces modifications et le problème de SSO persiste.
Après plusieurs reconstructions, j’ai réussi à faire fonctionner à nouveau le SSO en le ramenant à la version v3.3.2, il semble donc que quelque chose ait été introduit dans la v3.3.3 qui a cassé la prise en charge du SSO.
J’ai jeté un coup d’œil rapide à un git diff v3.3.2 v3.3.3 et rien d’évident n’a sauté aux yeux, mais il y a des changements liés à Discourse Connect.
Cependant, je soupçonne que cela va commencer à toucher plus de monde à mesure qu’ils passeront à la version 3.3.3 et que les sessions utilisateur commenceront à expirer et à ne pas pouvoir être renouvelées. Peut-être que cela mérite un examen plus approfondi par quelqu’un qui connaît le code, en particulier le flux SSO ? /cc @sam
PS : Je ne sais pas si cela peut être pertinent : j’avais mis à jour vers la version 3.3.3 il y a plus d’un jour, mais les problèmes ne semblent apparaître que peu de temps après une reconstruction via la console il y a quelques heures (pour activer un CDN, mais l’annulation de cela n’a pas résolu le SSO).
Oui, dans le sens où la plupart des gens exécutent la branche tests-passés, mais non dans le sens où il s’agit de la dernière version de la branche stable, publiée cette semaine : 3.3.3: Security and maintenance release
C’est peu probable, mais générez-vous le nonce dans une session de navigateur différente, par exemple en effectuant les requêtes SSO à partir du backend de votre application, au lieu de faire passer les utilisateurs par le processus SSO à l’aide de redirections de navigateur ?
Il existe un paramètre de site caché appelé discourse_connect_csrf_protection qui est activé par défaut. Pour autoriser les requêtes SSO à être effectuées en dehors de la session d’un utilisateur, il doit être désactivé.
Je suppose que ce paramètre était en place dans la version 3.3.2, mais il a peut-être été ajouté plus tard.
Ce n’est pas le cas – nous avons une implémentation assez standard de ce qui est décrit dans Setup DiscourseConnect - Official Single-Sign-On for Discourse (sso) en suivant les redirections. Cela fonctionne sans problème depuis quelques années et nous n’y avons pas touché.
Bien que nous ne fassions rien d’inhabituel en matière de SSO, j’ai quand même essayé en le désactivant dans la console Rails et tout ce que cela a fait pour moi, c’est de supprimer le message d’erreur. En d’autres termes, lorsque le fournisseur SSO redirigeait vers Discourse, au lieu de l’erreur La connexion au compte a expiré, veuillez réessayer de vous connecter., il n’y avait aucun message (erreur ou autre) – mais, malheureusement, toujours déconnecté.
Je me raccroche aussi à des brindilles car c’est assez étrange. Je pense que le fait que le problème ne se soit pas manifesté lors de notre mise à jour initiale vers la version 3.3.3 via l’interface web, mais seulement (~36h) plus tard après une reconstruction de la console, pourrait être un indice, mais je n’en sais pas assez sur les différences entre les deux.
J’ai essayé de repasser à la version 3.3.3 et le problème est revenu immédiatement. Revenir à la version 3.3.2 a de nouveau fait fonctionner le SSO.
Je soupçonne que le problème ici n’est pas le correctif de sécurité DiscourseConnect, mais plutôt le changement nginx. Sur tests-passed, nous avons dû faire un suivi jeudi car cela causait des problèmes dans certains environnements et un autre utilisateur sur Github a signalé des problèmes CSRF.
Je suis heureux de signaler que cela a fonctionné !
J’apprécie que vous ayez pris le temps de vous pencher sur ce problème, surtout un week-end et étant donné que stable et SSO sont un peu spécifiques, mais j’espère que cela aidera d’autres personnes également. Merci !
