Problèmes de connexion SSO Sporadic Discourse avec nonce expiré

Nous utilisons DiscourseSSO et, sporadiquement, les utilisateurs rencontrent des problèmes de connexion (similaires à Sporadic issue wp-discourse/SSO: Nonce has already expired). J’essayais de déboguer cela en ajoutant des journaux supplémentaires et, par chance, j’ai rencontré le problème après quelques jours. Pour être clair, la connexion fonctionne la plupart du temps, c’est juste que sporadiquement (peut-être pendant 5 minutes par jour) les utilisateurs rencontrent des problèmes de connexion.

Nous utilisons une configuration de sous-dossier sur un cluster multi-nœuds, en utilisant une base de données partagée externe et Redis si cela a une importance. Il y a deux scénarios d’échec :

  1. Le nonce a expiré
    Lorsque l’utilisateur est redirigé vers /session/sso_login, SessionController ne reçoit pas l’id de session dans la session et ne peut donc pas rechercher le nonce. J’ai essayé de journaliser la session (Rails.logger.warn(\"Verbose SSO log: Session #{session.keys.map {|key| [key, session[key]].join('=')}.join(',')}\")) et cela a affiché une session vide. J’ai vérifié que le navigateur envoie le cookie “_forum_session” tel que reçu dans la requête précédente et que le cookie est journalisé sur le serveur si la journalisation est activée dans SessionController (Rails.logger.warn(\"Verbose SSO log: Cookies #{cookies.map {|cookie| cookie.join('=')}.join(',')}\")).

  2. La connexion se termine mais l’utilisateur reçoit une erreur de connexion à l’écran
    Lorsque l’utilisateur est redirigé vers /session/sso_login, SessionController est capable de vérifier les données SSO et de connecter l’utilisateur (je vois Verbose SSO log: User was logged on user5 dans les journaux). Mais lorsqu’il redirige l’utilisateur vers /forums/latest, l’utilisateur voit une erreur à l’écran. J’ai remarqué que dans le flux de travail fonctionnel, cette action efface/renvoie un cookie vide “cn”, mais dans le scénario d’échec, elle met simplement à jour et renvoie le cookie “_t”. Je suppose que ce scénario est également lié à des données de session manquantes.

Si nous attendons environ 5 minutes et réessayons, tout recommence à fonctionner correctement.

Je n’ai pas testé si tous les utilisateurs qui accèdent au site à ce moment-là rencontrent le problème ou non, mais on m’a dit anecdotiquement que plusieurs utilisateurs l’ont rencontré une fois sur notre instance.

Bonjour !

Que utilisez-vous pour la configuration du sous-dossier ? Si vous avez une sorte de pare-feu d’application web devant Discourse, il pourrait être utile de vérifier les problèmes de mise en cache. D’après notre expérience, c’est la première chose à écarter.

Merci pour votre réponse Leonardo. Nous utilisons nginx comme passerelle principale qui envoie des URL basées sur le chemin à nginx à l’intérieur du conteneur Discourse.

J’ai ajouté ces deux lignes au début de session_controller.rb/sso et session_controller.rb/sso_login

    if SiteSetting.verbose_discourse_connect_logging
      Rails.logger.warn("Verbose SSO log: Cookies #{cookies.map {|cookie| cookie.join('=')}.join(',')}")
      Rails.logger.warn("Verbose SSO log: Session #{session.keys.map {|key| [key, session[key]].join('=')}.join(',')}")
    end

Pour le premier scénario d’échec mentionné ci-dessus, j’ai obtenu ce qui suit pour /sso (sur le nœud1 du cluster multinœud)

Verbose SSO log: Cookies cn=12,_forum_session=ZjBveGorRVN1bU0zeGRKVHZtWUZDamUxTUJSUkJHUDZDaHhLMkh3U0lXMlpCYS9PTnpJWEovcTlZVDFTSTJuNkVNUE9NdlNvVWlidStIdk9SeTlRYzZ5YVp0N0pXdmhnTldlaSt4d1o3TC9mUm1nSUhsOUtiWFRyVGZBYkJLRHRRR0lFZmM0RkVxLzl0V2JEODR4NGMxQUJvOGhpdVc0c2JsdDFESHo2TWxJPS0tRXZTL0FHZlM1Yy9QVWJkc2xaaTYvUT09--36fa626c698a401db1e7f13276ee6bfde16dea77,sessid=6b4afa7755dc9aa54e3fb16453a28324,<ADDITIONAL_COOKIES_REDACTED>
Verbose SSO log: Session 
Verbose SSO log: Setting nonce 8199453c67e347124ecb2e57e5738336 with key SSO_NONCE_8199453c67e347124ecb2e57e5738336

et ce qui suit pour /sso_login (sur le nœud2 du cluster multinœud)

Verbose SSO log: Cookies cn=12,_forum_session=WFRkNThYYUZwUnlOQjF5VHdUZGRUWE1UNUx2a3Z5ZlJCOGl0VFRRUlF2bm5vQUQzMWdaUVZVUnJkNmdIUjlRTE52d1B5MXJnV0svWkJMRWZrOU5XellvV0IzMTBScERwM0lzT3VIUWc2SEppb2xpTlkxaFpuc1dvU2d4SkdZRXFYYjJzakRQTXFmS2lYTlhxVEd5Zi9nQ3dZQnVUR1pDSndScGZhcVNJOW1ZPS0tNFduSE1YRDk5cWdMRXNsWnBzbDVhZz09--00ab1b89ff4cf05c9f3f3ed71eec9c0c4557f032,sessid=6b4afa7755dc9aa54e3fb16453a28324,<ADDITIONAL_COOKIES_REDACTED>
Verbose SSO log: Session 
Verbose SSO log: Checking nonce 8199453c67e347124ecb2e57e5738336 with key SSO_NONCE_8199453c67e347124ecb2e57e5738336
Verbose SSO log: Nonce is incorrect, was generated in a different browser session, or has expired

Sur le serveur Redis, je vois bien la clé nonce

redis:6379[3]> KEYS "*NONCE*"
1) "default:3aa05452fdd8fd4a93481eb8afa90f3aSSO_NONCE_8199453c67e347124ecb2e57e5738336"
2) "default:21639ca4bef85f68c1d72824e3a49bd6SSO_NONCE_7d54c965762e6861799f62ef7c5cfa60"
3) "default:_CACHE:USED_SSO_NONCE_86886a948684ff110d4830919d4e6de5"
4) "default:_CACHE:USED_SSO_NONCE_d04fdbf483fe61129a6fcc54087cb4e4"
5) "default:f7c87c11539908b30f9e307ef05d3f18SSO_NONCE_90a6a6997b7bd5d75eac1ac0cfc6dee2"

Ma préoccupation est que Session soit vide pour /sso_login.

Je relance le sujet, si quelqu’un a une suggestion.

le site est-il public par hasard ? Ce serait utile si nous pouvions le déboguer en ligne.

2 « J'aime »

Oui, c’est le cas, j’enverrai l’adresse dans un message privé.

Mise à jour : envoyé par message privé

1 « J'aime »

La connexion échoue-t-elle pour tous les utilisateurs en même temps ? Ou cela se produit-il à des moments différents pour chaque utilisateur ?

Le fait que cela recommence à fonctionner après un certain temps me fait me demander s’il y a une mise en cache impliquée. Votre configuration NGINX, ou tout autre proxy intermédiaire (par exemple, Cloudflare), effectue-t-il une mise en cache ?

Cela plante pour tous les utilisateurs pendant cette courte durée. Ma première hypothèse était qu’un nœud intermédiaire modifiait les données, mais lorsque j’ai enregistré les cookies depuis le contrôleur (comme expliqué ci-dessus), j’ai pu voir les cookies. Y a-t-il autre chose que je devrais vérifier également ?

Je relance le sujet.

3 messages ont été divisées dans un nouveau sujet : Client WordPress DiscourseConnect - nonce expiré

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.