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
Ich kann dazu nichts Aktuelleres finden. Das maximale Sitzungsalter kann mindestens auf eine Stunde festgelegt werden.
Das ist in einer gemeinsamen Umgebung nicht hilfreich.
Gibt es hierzu kürzlich etwas, das das Problem löst? Im Wesentlichen benötige ich, dass der Benutzer vergessen wird, wenn der Browser geschlossen wird und der Benutzer sich mit SSO angemeldet hat.
Vielen Dank
Genau das hat mein Patch bewirkt, wurde aber wieder rückgängig gemacht 
Du kannst den Code prüfen und ihn in ein Plugin übertragen.
Eine völlig nicht-Discourse-Frage:
Wie kann das überhaupt passieren? Vermutlich:
OK, das ist eine Sicherheitsbedrohung – ich werde einen neuen Thread eröffnen.
Luke, die ganze Welt lebt nicht in streng kontrollierten Büroumgebungen.
Nehmen Sie offene Zugangsstellen innerhalb einer akademischen Einrichtung oder Computer in Bibliotheken usw. Viele betrachten die Bereitstellung einer Browseroberfläche nicht als Sicherheitsrisiko.
Ich stimme völlig zu, dass Menschen ihre Hardware und Software so konfigurieren können, dass dieses Problem nicht auftritt, aber nicht jeder führt diese Konfiguration durch. Daher würde ich sagen, dass wir, indem wir unseren Nutzern ein Forum bieten, in dem wir wissen, dass Sicherheitslücken bestehen, wenn die zugrundeliegende Hardware und Software nicht bestimmungsgemäß konfiguriert sind, selbst verantwortlich werden.
Das ist eine berechtigte Frage. Umgebungen, in denen häufig eine gemeinsam genutzte Desktop-Umgebung genutzt wird, sind unter anderem Bibliotheken, Schulen und Krankenhäuser, wobei es noch weitere gibt. Wie Sie sich vorstellen können, spielen dabei Faktoren wie der Fokus auf Benutzerfreundlichkeit (von Erstklässlern zu erwarten, sich ihren Benutzernamen zu merken, ist schon schwierig genug; jetzt noch ein Passwort hinzuzufügen, das weder den Benutzernamen noch den Vornamen enthält und zudem Ziffern und Sonderzeichen umfasst? Ha!), das Fehlen eindeutiger Benutzer (Bibliotheken verzichten häufig auf Benutzernamen, da dies als Form der Nutzerüberwachung empfunden werden könnte, was vielen in Bibliotheksumgebungen missfällt) sowie die Anforderung an extrem schnelle Systemreaktionen (Krankenhäuser haben keine Zeit für Anmeldevorgänge, wenn jemand in der Notaufnahme stirbt; daher haben sie meiner Erfahrung nach nie eindeutige Anmeldungen pro Arzt, Krankenschwester oder Assistent) eine entscheidende Rolle.
Daher liegt es an den Anwendungen, für Sicherheit zu sorgen (Defense-in-Depth sollte ohnehin angewendet werden). Wenn eine Anwendung diese Sicherheit nicht bietet, wird sie schlicht nicht genutzt, da Sicherheit nach wie vor erforderlich ist.
Einige dieser Umgebungen mögen nicht das primäre Ziel von Plattformen wie Discourse sein, doch bei korrekter Einrichtung könnte Discourse die Abläufe in jedem dieser Bereiche problemlos unterstützen. Kinder und Erwachsene können innerhalb einer gruppen- und klassenspezifischen Umgebung Informationen austauschen. Auch wenn Personen in Bibliotheken möglicherweise keine Bibliotheksanmeldedaten haben, nutzen sie diese Computer dennoch, um sich mit ihren eigenen Benutzernamen und Passwörtern bei Systemen weltweit anzumelden (was ich jedoch niemals tun würde). Krankenhäuser könnten Discourse für die Kommunikation innerhalb oder zwischen Krankenhäusern nutzen, um Ideen zu bestimmten Themen, Verfahren usw. auszutauschen. In all diesen Fällen würde Discourse vermutlich eine vollständige Anmeldung für postende Benutzer voraussetzen.
In vielen dieser Fälle kommt auch Single Sign-On (SSO) infrage, das bei korrekter Einrichtung sowohl die Sicherheit als auch die Benutzerfreundlichkeit erhöht. Das Problem dabei ist jedoch, dass ein persistenter Cookie, der standardmäßig auf zwei (2) Monate eingestellt ist (!!), dazu führt, dass jeder, der in den nächsten Monaten an diesen Computer kommt, automatisch als der letzte Benutzer angemeldet wird. Die Einstellung lässt sich zwar auf nur eine (1) Stunde verkürzen, doch selbst das ist mehr als genug Zeit für unbeabsichtigte oder böswillige Probleme. Was kann man in ein paar Monaten alles tun?
Einige dieser Szenarien mögen abwegig klingen, doch sie sind einfach und relativ kostengünstig. Manche Menschen, die besser Bescheid wissen sollten, könnten bereit sein, ihren drei (3) Jahre alten Arbeitscomputer „zu verlieren
Es ist etwas alarmistisch, dies als Sicherheitsbedrohung zu bezeichnen. Umgebungen mit gemeinsam genutzten Computern bieten bereits Optionen, um sicherzustellen, dass ein Benutzer nicht in die Sitzung eines anderen eindringt, während er zwischen Computern wechselt:
Mir ist in den letzten zwei Jahrzehnten nur eine Client-Umgebung bekannt, in der die beste Option nicht möglich gewesen wäre.