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
Não consigo encontrar nada mais atualizado sobre isso. A idade máxima da sessão pode ser definida com um mínimo de 1 hora.
Isso não é útil quando o computador está sendo usado em um ambiente compartilhado.
Houve algo recente sobre isso que resolva o problema? Basicamente, preciso que o usuário seja esquecido quando o navegador for fechado e o usuário tiver feito login com SSO.
Obrigado
Foi exatamente isso que meu patch fez, mas ele foi revertido 
Você pode verificar o código e adaptá-lo para um plugin.
Questão totalmente fora do contexto do Discourse:
Como isso até acontece? Presumivelmente:
Ok, então isso é uma ameaça de segurança — vou iniciar um novo tópico.
Luke, o mundo inteiro não vive em ambientes de escritório estritamente controlados.
Considere sites de acesso aberto dentro de instituições acadêmicas e máquinas em bibliotecas, etc. Muitos não veem o fornecimento de uma interface de navegador como um risco de segurança.
Concordo totalmente que as pessoas podem configurar seu hardware e software para evitar esse problema, mas nem todos fazem essa configuração. Portanto, ao fornecer um fórum aos nossos usuários onde sabemos que existem falhas de segurança se o hardware e o software em que ele roda não estiverem configurados de determinada maneira, isso nos torna responsáveis, diria eu.
Essa é uma pergunta justa. Ambientes que comumente utilizam uma experiência de desktop compartilhada incluem bibliotecas, escolas e hospitais, embora existam outros. Como você pode imaginar, os fatores determinantes incluem o foco na facilidade de uso (pedir que crianças do primeiro ano lembrem seu nome de usuário já é difícil o suficiente, mas agora adicionar uma senha que não inclua seu nome de usuário ou nome pessoal, e que tenha números e caracteres especiais? ha!), a falta de usuários únicos (bibliotecas frequentemente não têm nomes de usuário porque isso poderia ser uma forma de rastreamento de usuários, o que incomoda muitos no ambiente de bibliotecas) e a necessidade de respostas muito rápidas do sistema (hospitais não têm tempo para janelas de login quando alguém está morrendo na sala de emergência, então eles (na minha experiência) nunca têm logins únicos por médico/enfermeiro/auxiliar).
Como resultado, cabe às aplicações serem seguras (a defesa em profundidade deve se aplicar de qualquer maneira), e quando uma aplicação não fornece essa segurança, ela simplesmente não é usada, pois a segurança ainda é necessária.
Alguns desses ambientes podem não ser o público-alvo principal de algo como o Discourse, mas ele poderia ser facilmente utilizado para facilitar as operações em qualquer um desses ambientes, se configurado corretamente. Crianças e adultos podem compartilhar informações em uma turma dentro de um grupo específico para aquela turma. Embora pessoas em bibliotecas possam não ter logins de biblioteca, elas ainda usam esses computadores para fazer login em sistemas de todo o mundo com seus próprios nomes de usuário/senhas (embora eu nunca faria algo assim). Hospitais poderiam usá-lo para comunicações intra-hospitalares ou inter-hospitalares, compartilhando ideias sobre determinados tópicos, procedimentos, etc., e em todos esses casos o Discourse presumivelmente teria um login completo para os usuários que postam.
Em muitos desses casos, o Single Sign-On (SSO) também pode ser aplicado, trazendo tanto maior segurança quanto conveniência quando configurado corretamente. O problema aqui é que um cookie persistente com duração padrão de dois (2) meses (!!) significa que qualquer pessoa que chegar a esse computador nos próximos meses entrará magicamente como o usuário que estava lá por último. A configuração pode ser reduzida para apenas uma (1) hora, mas isso ainda é tempo suficiente para problemas acidentais ou maliciosos. O que você pode fazer em dois meses?
Emprestar seu computador a um amigo.
Doá-lo para alguém que precisa quando você não precisa mais (doação).
Cansar-se de um computador, desligá-lo, vendê-lo no eBay, enviá-lo ao redor do mundo e ter alguém usá-lo.
Sofrer um assalto e roubo em sua casa ou local de trabalho.
Ter um colega de trabalho comprometendo seu computador durante a noite, iniciando a partir de mídia externa e extraindo cookies persistentes úteis.
Ser alvo de alguém com uma agenda, no Craigslist/mídia social, etc., oferecendo comprar seu computador por uma quantia insana para obter o que está lá com sua permissão.
Algumas dessas situações podem parecer exageradas, mas também são fáceis e relativamente baratas. Algumas pessoas que deveriam saber melhor podem estar dispostas a “perder” seu computador de trabalho de três (3) anos e obter um novo como resultado, em troca de US$ 1.000 de alguém online. Muitos nesses fóruns podem ver através disso, mas nem todos são honestos ou têm segurança financeira.
É um pouco alarmista chamar isso de ameaça à segurança. Ambientes com computadores compartilhados já possuem opções para garantir que um usuário não possa acessar a sessão de outro ao alternar entre computadores:
Nos últimos vinte anos, conheço apenas um ambiente de cliente onde a opção principal não teria sido possível.