My problem is when using SSO, so I really need to be a site setting.
When we detect that the SSO is down we nuke the cookies, but if the user left the pc with a valid SSO session, and other user opens it, he can be logged as someone else.
Setting expires to session may solve this.
Guys, I traced down making the _t cookie having a smaller expires.
The problem is that Discourse doesn’t seen to handle this very well atm.
We get a /login redirect but the it results in a ajax error instead of rendering the /login page properly.
Should I add special code to handle this expiration on the $.ajax function?
Probably best to consult with @sam first before proceeding, but in general, I would like it if people could set their site’s cookies to expire, say, weekly if they want that to happen.
The _t cookie is the wrong spot imo, we should start off by adding a column to user table that specifies when the auth token was created
Then it is trivial to expire cause a site setting can check for stale tokens when doing current user resolution
I do not like the idea of having this logic up to clients, cause clients can cheat
Since a timed cookie is a very bad idea, I have done a switch between Session and Permanent. Permanent still default, so no changes for most people.
My use case is enterprise communities, where sharing computers happen very often. People are used to services not persisting trough a browser restart or a computer restart and are posting on each other account 
.
Keep in mind we have 100k+ non tech employees 
Sure @sam will need to review.
The feature provided by @Falco got removed by commit a9207dafa
It would be great to bring back this feature. Because some users don’t perform an explicit logout by hitting the button. They’ll just close the browser assuming this would terminate their session as well. But the session will be still alive.
Please let the admin decide whether or not to use permanent sessions. It is a valuable feature for specific communities and use cases.
Now that my auth changes are all done a ton of stuff is easily on the table.
Personally I think the best change we can make here is:
We already have “maximum session age” which is set to 1440 hours, by heavily reducing it we can “sort of” approximate a session based cookie, except that unlike a session based cookie, closing and opening tabs will keep you logged on.
These 3 site settings and bits of UI needed for “stay signed in” option are probably doable in 1-2 days of work.
@codinghorror your call if
We only need the 1440 value as a site setting the other stuff can be ignored.
Does anyone know if this was ever implemented? I would like the ability to control when a user’s session times out if possible.
I can’t recall if we added the session duration site setting, do you remember @sam?
Yep, it’s there in admin:
The default is quite generous – around two months. I’m not sure if it supports fractional values, though – I can see that some people would prefer very short sessions (five to fifteen minutes), but the setting itself is in hours.
Yeah we have “maximum session age”: User will remain logged in for n hours since last visit
Set to 1440 by default
Je ne trouve rien de plus récent à ce sujet. L’âge maximum de session peut être défini à 1 heure au minimum.
Cela ne sert à rien lorsque l’ordinateur est utilisé dans un environnement partagé.
Y a-t-il eu des développements récents sur ce sujet qui résolvent le problème ? Essentiellement, j’ai besoin que l’utilisateur soit oublié lorsque le navigateur est fermé et que l’utilisateur s’est connecté avec SSO.
Merci
C’est exactement ce que mon correctif faisait, mais il a été rétabli 
Vous pouvez examiner le code et l’adapter dans un plugin.
Question totalement hors sujet par rapport à Discourse :
Comment cela peut-il arriver ? On pourrait supposer que :
OK, donc il s’agit d’une menace pour la sécurité — je vais lancer un nouveau sujet.
Luke, le monde entier ne vit pas dans des environnements de bureau strictement contrôlés.
Prenons les sites à accès ouvert au sein d’une institution académique et les machines dans les bibliothèques, etc. Beaucoup ne considèrent pas la fourniture d’une interface navigateur comme un risque de sécurité.
Je suis tout à fait d’accord pour dire que les personnes peuvent configurer leur matériel et leurs logiciels pour éviter ce problème, mais tout le monde ne fait pas cette configuration. Ainsi, en offrant à nos utilisateurs un forum où nous savons qu’il existe des failles de sécurité si le matériel et les logiciels sur lesquels il s’exécute ne sont pas configurés d’une certaine manière, cela nous rend responsables, je dirais.
C’est une question tout à fait légitime. Les environnements qui utilisent couramment un bureau partagé incluent les bibliothèques, les écoles et les hôpitaux, bien qu’il en existe d’autres. Comme vous pouvez l’imaginer, les facteurs déterminants sont la priorité donnée à la facilité d’utilisation (demander à des enfants de première année de se souvenir de leur nom d’utilisateur est déjà difficile, mais ajouter un mot de passe qui ne contient ni leur nom d’utilisateur ni leur prénom, et qui comprend des chiffres et des caractères spéciaux ? ha !), l’absence d’utilisateurs uniques (les bibliothèques n’ont souvent pas de noms d’utilisateur car cela pourrait constituer une forme de traçage des utilisateurs, ce qui déplaît à beaucoup dans le milieu bibliothécaire), et l’exigence de réponses très rapides de la part du système (les hôpitaux n’ont pas le temps de laisser des fenêtres de connexion s’afficher lorsque quelqu’un est en train de mourir aux urgences, donc ils n’ont, selon mon expérience, jamais de connexions uniques par médecin/infirmier/assistant).
Par conséquent, il incombe aux applications d’être sécurisées (la défense en profondeur devrait de toute façon s’appliquer), et lorsqu’une application ne fournit pas cette sécurité, elle n’est tout simplement pas utilisée, car la sécurité reste indispensable.
Certains de ces environnements ne constituent peut-être pas la cible principale d’une solution comme Discourse, mais elle pourrait facilement être utilisée pour faciliter les opérations dans l’un ou l’autre de ces contextes si elle est correctement configurée. Les enfants et les adultes peuvent partager des informations au sein d’une classe, dans un groupe spécifique à cette classe. Bien que les personnes dans les bibliothèques n’aient pas de connexions bibliothécaires, elles utilisent toujours ces ordinateurs pour se connecter à des systèmes partout avec leurs propres noms d’utilisateur et mots de passe (bien que je ne ferais jamais une telle chose). Les hôpitaux pourraient l’utiliser pour des communications intra-hospitalières ou inter-hospitalières, le partage d’idées sur des sujets donnés, des procédures, etc., et dans tous ces cas, Discourse aurait vraisemblablement une connexion complète pour les utilisateurs qui publient.
Dans de nombreux cas, l’authentification unique (Single Sign-On, SSO) peut également s’appliquer, apportant à la fois une sécurité accrue et plus de commodité lorsqu’elle est correctement configurée. Le problème ici est qu’un cookie persistant par défaut valable deux (2) mois (!!) signifie que n’importe qui accédant à cet ordinateur dans les prochains mois se retrouvera magiquement connecté en tant que l’utilisateur qui y était la dernière fois. Le paramètre peut être réduit à aussi peu qu’une (1) heure, mais cela reste largement suffisant pour des problèmes accidentels ou malveillants. Que peut-on faire en deux mois ?
Prêter son ordinateur à un ami.
Le donner à quelqu’un qui en a besoin lorsque vous n’en avez plus (donation).
Se lasser d’un ordinateur, l’éteindre, le vendre sur eBay, l’expédier aux quatre coins du monde, et laisser quelqu’un l’utiliser.
Subir une effraction et un vol à votre domicile ou sur votre lieu de travail.
Avoir un collègue compromettre votre ordinateur pendant la nuit, démarrer sur un support externe et extraire des cookies persistants utiles.
Être ciblé par quelqu’un ayant un agenda, sur Craigslist, les réseaux sociaux, etc., proposant d’acheter votre ordinateur pour un montant fou afin d’obtenir ce qui s’y trouve avec votre permission.
Certains de ces scénarios peuvent sembler tirés par les cheveux, mais ils sont aussi faciles et relativement peu coûteux. Certaines personnes qui devraient pourtant savoir mieux pourraient être prêtes à « perdre » leur ordinateur de travail de trois (3) ans et en obtenir un nouveau en échange de 1 000 $ de la part d’un inconnu en ligne. Beaucoup sur ces forums pourraient voir à travers cette supercherie, mais tout le monde n’est pas honnête ou financièrement à l’aise.
C’est un peu alarmiste de qualifier cela de menace pour la sécurité. Les environnements avec des ordinateurs partagés disposent déjà de solutions pour empêcher un utilisateur d’accéder à la session d’un autre lors du déplacement entre les ordinateurs :
Je ne connais qu’un seul environnement client au cours des deux dernières décennies où l’option principale n’aurait pas été possible.