Bonjour, j’apprends que plusieurs de mes membres du forum sont déconnectés automatiquement après 20 à 30 minutes.
J’utilise l’authentification unique (SSO), je me demande donc si le problème pourrait provenir du fait qu’ils se connectent au site principal, puis accèdent à Discourse (ce qui démarre une nouvelle session ici ?), retournent au site principal (ce qui signifie que Discourse est inactif), puis retournent sur Discourse et se retrouvent déconnectés d’une manière ou d’une autre.
(Cela n’a pas tout à fait de sens, car chaque fois qu’ils accèdent à Discourse, cela devrait remettre le « délai d’inactivité » à 0, non ?)
J’ai trouvé quelques discussions sur les délais d’attente, etc., ici sur Meta, mais aucune ne semble apporter une réponse claire.
Question : existe-t-il un paramètre pour empêcher les membres d’être déconnectés tant qu’ils ne sont pas inactifs pendant une durée X ? Je n’arrive pas à le trouver.
Je vois bien dans mes paramètres Discourse que mon « durée maximale de session » est définie à 1 heure, mais je ne pense pas que cela ait vraiment d’impact avec une implémentation SSO, n’est-ce pas ? (Notez que lorsqu’un membre se déconnecte sur mon site principal, j’envoie un message /logout à Discourse, simplement pour tout garder propre. Et chaque fois qu’un membre effectue une activité quelconque sur Discourse, je mets à jour l’heure de dernière activité sur mon site principal, donc ce n’est pas le site principal qui expire. J’ajoute actuellement du code de débogage supplémentaire pour confirmer que tout fonctionne comme prévu.)
Cela s’applique bien au SSO, donc c’est probablement la source de votre problème. Après 1 heure d’inactivité, la session Discourse sera terminée et les utilisateurs devront se réauthentifier via SSO.
C’est bien, et tout à fait acceptable… après 1 heure d’inactivité, ils devraient être déconnectés.
Le problème, c’est que je reçois des rapports de personnes déconnectées après 20 à 30 minutes.
Existe-t-il un paramètre pour ce délai d’inactivité d’une heure ? Comme je l’ai mentionné dans mon message initial, je ne parviens pas à le trouver… et cela semble être le premier endroit à vérifier, non ?
Juste pour écarter la cause la plus évidente… est-il possible que les gens se trompent sur l’heure exacte ? 30 minutes et 1 heure ne sont pas si différents
Pour continuer le débogage, je suggère que la prochaine étape consiste à examiner les données disponibles dans les tables user_auth_tokens et user_auth_token_logs. Elles contiennent toutes les informations sur les jetons de session et leur expiration.
Hmm. Lorsque les utilisateurs consultent les forums et lisent des sujets, etc., si ils effectuent une action génératrice d’événement (create_post, create_topic, edit_post, etc.), je reçois un message via le webhook. Cela indique au site principal qu’ils sont toujours actifs, ce qui me permet de mettre à jour la valeur « Last Click » de leur session et d’éviter ainsi une déconnexion. C’est normal. Tout va bien.
Cependant, si un membre se contente de lire des messages pendant un certain temps… son temps d’inactivité sur Discourse est réinitialisé à chaque fois qu’il effectue une action (ce qui est bien), mais mon site principal ne reçoit aucun message webhook indiquant que l’utilisateur est actif. Ainsi, après une heure sans aucune activité (il semble qu’ils soient allés sur les forums et aient quitté leur ordinateur), le site principal suppose qu’ils sont déconnectés et les déconnecte.
Il semble qu’il y ait un trou dans la logique ici. Pour une mise en œuvre correcte du SSO, ne devrait-il pas exister un moyen pour Discourse de m’indiquer si la session d’un utilisateur est active (même s’ils se contentent de lire) ? Peut-être que Discourse devrait envoyer un ping toutes les 5 minutes si le membre est actif mais n’a généré aucun autre message webhook.
Ou peut-être que lorsque mon site pense qu’un utilisateur a expiré, je devrais contacter Discourse pour demander si l’utilisateur est actif de leur côté. Existe-t-il un moyen de faire cela ? (Je vois Is there an endpoint to check if a user is logged in - #3 by pfaffman, mais je ne suis pas tout à fait sûr que ce soit ce qu’il me faut, et /session/current.json ne figure pas dans la documentation de l’API.) Cela générerait cependant un grand nombre d’appels API : je déconnecte environ 15 à 20 utilisateurs chaque minute sur mon site pour inactivité, ce qui signifierait un appel pour chacun (et peut-être plus d’un appel si je n’ai pas de cache local de leur ID Discourse).
Chaque point de terminaison de profil contient une valeur last_seen, que vous pourriez utiliser.
Je ne pense pas avoir vu ce type de configuration dans aucun protocole SSO, et nous n’avons pas reçu de demandes pour ce genre de fonctionnalités. Plus couramment, les gens maintiennent les deux systèmes indépendants.
Si vous souhaitiez vraiment créer un webhook pour « utilisateur vu », vous pourriez peut-être le faire en utilisant un plugin personnalisé.
Je ne suis pas sûr de comprendre ce que vous entendez par « maintenir les deux systèmes indépendants » ? Faites-moi savoir si je passe à côté d’une solution évidente pour résoudre le problème que j’ai exposé, s’il vous plaît !
Sinon, il semble que mes options soient les suivantes :
Lorsqu’un utilisateur expire sur le site principal, avant de le déconnecter, appeler Discourse et vérifier la valeur last_seen pour voir si le membre a réellement été actif sur les forums (sans pour autant avoir effectué une action générant un appel de webhook). Avantages : facile à mettre en œuvre. Inconvénients : cela générera un grand nombre d’appels API, ce qui est déjà un problème que je dois gérer en contournant les limites de débit.
Créer mon propre plugin pour envoyer un ping à mon site principal de temps en temps, afin de pouvoir mettre à jour la dernière activité de l’utilisateur sur mon site principal. Avantages : cela semble être la solution la plus « logique » (indiquer l’activité via un message push) ; assez élégant. Inconvénients : pas facile à implémenter.
Modifier le délai de déconnexion sur mon site principal à 2 heures. Avantages : facile à mettre en œuvre. Inconvénients : y en a-t-il ?
Ne pas s’en soucier. Les utilisateurs sont déconnectés au milieu de leur session Discourse et se plaignent à grands cris. C’est ce que j’ai actuellement. Avantages : facile à mettre en œuvre, lol. Inconvénients : une expérience utilisateur très médiocre.
Ai-je oublié quelque chose ?
Il semble que la solution n°3 serait une bonne réponse, bien que je doive réfléchir aux conséquences d’un délai de déconnexion plus long sur le site principal.
Je préfère toujours la solution n°1 comme meilleur choix, mais alors je dois trouver comment éviter autant de problèmes de limites de débit. J’aimerais qu’il existe un moyen de désactiver globalement toutes les limites de débit dans Discourse (et nginx, puisque j’utilise l’installation Docker de Discourse), point final. Je n’en ai besoin d’aucune. C’est uniquement mon site principal qui communique avec mon instance Discourse. Je n’autorise pas les clés API utilisateur et je suis le seul à posséder une clé API système. C’est un système complètement fermé et les limites de débit ne font que (constamment) m’entraver. Je suppose que c’est un autre sujet.
Si vous devez conserver le comportement que vous avez décrit, alors oui, je pense qu’il s’agit bien des 4 options. Mais si vous modifiez légèrement ce comportement, cela fonctionnera mieux avec les outils disponibles.
L’élément inhabituel de votre configuration est :
Vous mettez fin à la session Discourse à chaque fois que la session expire sur votre site principal. Si vous supprimez cette partie, je pense que la configuration correspondra aux configurations typiques.
Vous pouvez toujours appeler /logout lorsqu’un utilisateur se déconnecte explicitement de votre site principal. Il suffit de ne pas l’appeler lorsque la session expire naturellement.
On ne peut pas le dire d’après l’OP, mais êtes-vous en train de gérer un site très spécialisé où les gens partagent des informations ultra-sensibles, ou où la plupart des utilisateurs se connectent depuis des ordinateurs publics partagés ou quelque chose de similaire ?
De loin, la solution la plus simple ici semble être de ne pas être hyper-agressif dans l’expiration des sessions utilisateur et le forçage de la déconnexion. Ma préférence en tant qu’utilisateur est toujours de « ne jamais me déconnecter sauf si je clique spécifiquement sur déconnexion ». Si cela n’est pas possible, pourriez-vous au moins le faire tous les un jour ou une semaine ou quelque chose comme ça ?
Je vois… c’est une bonne solution ; je pense que suffisamment de mes membres utilisent la case à cocher « me garder connecté » sur la page de connexion pour que le retour vers le site principal soit fluide. Si leur session a expiré sur le site principal, ils seraient reconnectés (de manière invisible) à ce moment précis. Hmm.
C’est un site destiné à un segment de la population très sensible à la vie privée. Mais je vois ce que vous voulez dire et je pense que je pourrais simplement faire comme vous (et David) le suggérez.
Merci beaucoup à vous deux. Je n’avais pas une bonne idée de la « vue d’ensemble » ici, ni de la manière dont d’autres sites gèrent ce genre de scénario… maintenant je la comprends et je vois quelques solutions possibles pour ma situation. Très apprécié !
et je vois quelques solutions possibles pour ma situation. Très apprécié !