Salut les gars !
Je gère l’authentification SSO dans mon backend PHP. Je commence par envoyer une requête cURL vers mon URL SSO (Communauté et formation pour entrepreneurs) afin d’obtenir le payload SSO et le SIG, puis je procède à la création de mon propre payload pour générer l’URL de redirection appropriée.
C’est là que ça devient bizarre…
Si j’accède à Communauté et formation pour entrepreneurs via mon navigateur, que je copie/colle le SSO et le SIG dans mon script, l’URL de redirection finale fonctionne.
Si je les récupère via cURL, la redirection finale affiche un message d’erreur et j’ai ceci dans mon journal :
Journal SSO détaillé : Le nonce a déjà expiré
Je suis complètement perdu… Le problème semble être apparu de nulle part et maintenant mes utilisateurs ne peuvent plus se connecter.
Est-ce que Discourse a modifié quelque chose pour empêcher les bots de pinguer /session/sso ?
simon
2
Oui, le nonce est désormais associé à la session de l’utilisateur pour lequel il a été généré. Il semble que le problème que vous rencontrez soit lié à ceci :
Au lieu d’envoyer une requête curl, il est attendu que l’utilisateur devant être authentifié visite /session/sso, soit en cliquant sur le bouton Se connecter du site, soit en étant redirigé vers /session/sso depuis votre application. Lorsqu’ils le font, ils seront redirigés vers votre application par Discourse. Le nonce présent dans cette charge utile sera alors valide.
C’est ce que j’ai dû faire pour résoudre le problème, mais cela rompt mon processus de connexion asynchrone. 
J’aimais vraiment procéder ainsi.
J’ai également essayé de le faire via Axios. Je m’attendais à ce que cela fonctionne puisque la requête provient du client. Cela ne semble pas fonctionner non plus.
Si vous trouvez un moyen d’implémenter un processus de connexion asynchrone, je serais ravi de recevoir vos conseils ! En tout cas, merci pour votre réponse, je l’apprécie grandement.