Hôpitaux : Je ne partage que ce que je sais être fait par expérience. Je reconnais que les écrans se verrouillent rapidement, mais cela ne correspond pas à une déconnexion du navigateur, encore moins à celle de l’utilisateur du système d’exploitation. Pouvez-vous imaginer ce que les gens feraient si l’ordinateur devait se connecter, appliquer les stratégies, configurer les connexions réseau, le tout avant de charger une application pour accomplir ce que les médecins et les infirmières doivent faire pendant qu’un patient est en train de mourir ? De même, les connexions n’utilisent généralement pas un nom d’utilisateur et un mot de passe, mais plutôt une carte d’identité accompagnée d’un court code PIN, pour la même raison. Les urgences, les blocs opératoires et la plupart des autres salles doivent toujours documenter les informations des patients ; là où j’ai travaillé, cela a été cohérent partout.
Bibliothèques : Des stratégies de redémarrage à la déconnexion existent et sont efficaces tant que les administrateurs vident manuellement les caches de tout ce qui se trouve sur la machine, mais j’ai vu tout autant d’endroits faire autrement (c’est l’une des nombreuses raisons pour lesquelles je n’ai jamais utilisé de postes de travail partagés, avec mes identifiants, jamais, en aucun cas). J’ai vu le même dispositif malheureux dans les hôtels et les cybercafés (ou les cafés) régulièrement, pour ce que cela vaut.
Il me semble étrange qu’une application prenne par défaut ce paramètre pour tous les utilisateurs dans toutes les installations. La sécurité n’est pas l’objectif principal de la plupart des gens lorsqu’ils configurent d’abord leurs ordinateurs, et la complexité est telle que c’est souvent le métier à temps plein de certains professionnels. Ceux qui configurent des ordinateurs pour le public devraient mieux savoir, mais les navigateurs ont l’idée des cookies de session pour faciliter aux développeurs d’applications la gestion de sessions lorsque cela est intuitif pour les utilisateurs.
Exiger que les utilisateurs comprennent qu’ils doivent manuellement effacer les cookies d’un site pour se déconnecter, alors que de nombreux sites expireront la session et la termineront également à la fermeture du navigateur, semble exiger trop des gens. Ne pas permettre l’alternative du tout, obligeant ainsi un utilisateur à se souvenir d’utiliser le lien de déconnexion spécifique de Discourse, devient un problème lorsque les utilisateurs manquent ce lien pour une raison quelconque ; à l’esprit :
L’utilisateur quitte Discourse en suivant un lien.
L’utilisateur quitte Discourse parce qu’il utilise l’onglet pour aller ailleurs explicitement.
L’utilisateur ferme l’onglet à la hâte pour se rendre à un cours, une réunion, etc.
Le navigateur plante pour une raison quelconque.
L’implémenteur SSO utilise SAML pour la connexion, mais ne sait pas que l’application nécessite une déconnexion explicite pour tuer la session de l’application.
De plus, deux (2) mois semblent être une DURÉE VRAIMENT LONGUE pour une persistance de connexion. Je sais que certains autres sites le font aujourd’hui, ou même plus longtemps, mais les utilisateurs peuvent généralement contrôler cela via ces cases à cocher « Ordinateur public », ce qui ne s’applique pas avec SSO, ou peut-être pas du tout (je ne suis pas un expert de Discourse).
Juste quelques réflexions supplémentaires à prendre en compte.