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
Non riesco a trovare nulla di più aggiornato su questo. L’età massima della sessione può essere impostata su un minimo di 1 ora.
Questo non è utile quando il computer viene utilizzato in un ambiente condiviso.
È stato introdotto qualcosa di recente che risolva il problema? In sostanza, ho bisogno che l’utente venga dimenticato quando il browser viene chiuso e l’utente ha effettuato l’accesso con SSO.
Grazie
Questo è esattamente ciò che faceva la mia patch, ma è stata annullata 
Puoi controllare il codice e portarlo in un plugin.
Domanda totalmente non inerente a Discourse:
Come può succedere una cosa del genere? Presumibilmente:
OK, quindi questa è una minaccia alla sicurezza: avvierò un nuovo thread
Luke, il mondo intero non vive in ambienti d’ufficio strettamente controllati.
Prendiamo, ad esempio, i siti a accesso aperto all’interno di istituzioni accademiche o i computer nelle biblioteche, ecc. Molti non considerano la fornitura di un’interfaccia browser come un rischio per la sicurezza.
Concordo pienamente sul fatto che le persone possano configurare l’hardware e il software per evitare questo problema, ma non tutti effettuano tale configurazione. Quindi, fornendo un forum ai nostri utenti dove sappiamo che esistono vulnerabilità di sicurezza se l’hardware e il software su cui gira non sono configurati in un certo modo, direi che ciò ci rende responsabili.
È una domanda sensata. Gli ambienti che utilizzano comunemente un’esperienza desktop condivisa includono biblioteche, scuole e ospedali, anche se ce ne sono altri. Come puoi immaginare, i fattori trainanti includono la facilità d’uso (chiedere a bambini di prima elementare di ricordare il proprio nome utente è già difficile di per sé, ma aggiungere una password che non includa il nome utente o il nome personale, con numeri e caratteri speciali? beh!), la mancanza di utenti unici (nelle biblioteche spesso non ci sono nomi utente perché ciò potrebbe costituire una forma di tracciamento degli utenti, cosa che molti negli ambienti bibliotecari trovano sgradevole) e la necessità di risposte molto rapide da parte del sistema (gli ospedali non hanno tempo da perdere con le finestre di accesso quando qualcuno sta morendo nel pronto soccorso, quindi, per esperienza, non hanno mai login unici per medici/infermieri/assistenti).
Di conseguenza, spetta alle applicazioni garantire la sicurezza (la difesa in profondità dovrebbe applicarsi comunque), e quando un’applicazione non fornisce tale sicurezza, semplicemente non viene utilizzata, poiché la sicurezza rimane un requisito fondamentale.
Alcuni di questi ambienti potrebbero non essere il bersaglio principale di qualcosa come Discourse, ma potrebbero facilmente essere utilizzati per facilitare le operazioni in uno qualsiasi di questi contesti se configurati correttamente. Bambini e adulti possono condividere informazioni su una classe all’interno di un gruppo specifico per quella classe. Anche se le persone nelle biblioteche potrebbero non avere login bibliotecari, utilizzano comunque quei computer per accedere a sistemi di tutto il mondo con i propri nomi utente e password (anche se io non lo farei mai). Gli ospedali potrebbero utilizzarlo per comunicazioni interne o inter-ospedaliere, per condividere idee su determinati argomenti, procedure, ecc., e in tutti questi casi Discourse presumibilmente richiederebbe un login completo per gli utenti che pubblicano.
In molti di questi casi, potrebbe essere applicato anche il Single Sign-On (SSO), offrendo sia maggiore sicurezza che comodità se configurato correttamente. Il problema qui è che un cookie persistente con scadenza predefinita di due (2) mesi (!!) significa che chiunque acceda a quel computer nei prossimi due mesi potrà magicamente entrare come l’ultimo utente che lo ha utilizzato. L’impostazione può essere ridotta a appena un (1) ora, ma ciò è comunque sufficiente per problemi accidentali o malintenzionati. Cosa si può fare in due mesi?
Prestitare il computer a un amico.
Donarlo a qualcuno che ne ha bisogno quando non lo si utilizza più (donazione).
Stancarsi di un computer, spegnerlo, venderlo su eBay, spedirlo in giro per il mondo e farlo utilizzare da qualcun altro.
Subire un’effrazione e un furto a casa o sul luogo di lavoro.
Avere un collega che compromette il computer durante la notte, avviandolo da supporti esterni e recuperando utili cookie persistenti.
Essere presi di mira da qualcuno con un’agenda, su Craigslist, social media, ecc., che offre di acquistare il tuo computer per una cifra folle per ottenere ciò che c’è dentro con il tuo permesso.
Alcuni di questi scenari potrebbero sembrare esagerati, ma sono anche semplici e relativamente economici. Alcune persone che dovrebbero saperla lunga potrebbero essere disposte a “smarrire” il loro computer da lavoro di tre (3) anni e ottenerne uno nuovo in cambio di 1.000 dollari da qualcuno online. Molti su questi forum potrebbero vedere attraverso l’inganno, ma non tutti sono onesti o finanziariamente sicuri.
Definire questa una minaccia alla sicurezza è un po’ allarmistico. Gli ambienti con computer condivisi hanno già opzioni per garantire che un utente non possa accedere alla sessione di un altro mentre si sposta tra i computer:
Conosco solo un ambiente client negli ultimi due decenni in cui l’opzione principale non sarebbe stata possibile.