Tempo limite de sessão

Entendo seu raciocínio, Stephen, mas isso não é alarmista.

Profissionais de TI lidam diariamente com usuários desinformados e/ou o chamado ‘usuário leigo’. Tentamos implementar sistemas que consigam lidar com todas as eventualidades, e isso não é fácil. Identidade é um tema crucial atualmente, e foi apenas durante os testes que descobrimos esse problema — um aviso prévio teria sido bem-vindo, especialmente considerando que isso já foi discutido (e corrigido uma vez) desde 2016.

Minha esperança era de que eu tivesse deixado algo passar ou que houvesse uma configuração incorreta, mas agora sei que o sistema está funcionando conforme o projetado. Vamos explorar alternativas externas para contornar isso e documentar para nossos usuários, e esperamos que, em algum momento no futuro, outras pessoas também exerçam pressão para que esse problema seja resolvido dentro do Discourse.

Mas e se o usuário esquecer de fechar o navegador? Como isso funciona?

Tenho curiosidade, @falco: por que o patch de 2016 foi revertido? É uma alteração insegura?

Alguns pontos válidos.

No entanto, fiquei bastante chocado com alguns dos seus exemplos:

Hospitais: Os que frequentou nos últimos anos certamente têm bloqueios únicos, a ponto de a enfermeira responsável pelos exames de sangue ter que fazer login novamente após se afastar por alguns segundos.

Na emergência, pode haver alguns sistemas especializados com acesso a dados relevantes para emergências, mas eles não deveriam ter acesso a informações de identificação pessoal (PII) ou ao fórum de chat do departamento.

Bibliotecas:
Todas as bibliotecas públicas locais que conheço (incluindo algumas em cidades muito pequenas com pessoal pouco familiarizado com tecnologia) possuem um ID de login genérico. (O mesmo para todos os usuários, afixado diretamente no monitor) Elas também têm uma política de reinicialização ao sair, e todos, incluindo as crianças, devem cumpri-la. A sequência de reinicialização inclui a limpeza automática do histórico, cache e cookies do navegador.

Não estou dizendo que uma política mais cuidadosa no lado do debate seria algo ruim; é apenas que algumas das situações “desencadeadoras” listadas neste tópico me alarmam, pois postagens no fórum atribuídas erroneamente são o menor de seus problemas.

A linha do tempo é:

  • 2012 a maio de 2016: O cookie de sessão do Discourse era sempre definido como permanente.

  • Maio de 2016 a julho de 2016: O cookie de sessão do Discourse era definido como permanente por padrão, mas uma configuração do site podia fazê-lo expirar ao fechar o navegador.

  • Julho de 2016 até hoje: O cookie de sessão do Discourse é definido para 1440 horas e é renovado com o uso. Uma configuração do site pode controlar o tempo máximo de vida. A configuração de cookie de sessão do navegador foi removida.

Foi removido principalmente porque:

Entendo que compartilhar computadores com estranhos seja um conceito bastante estranho em algumas partes do mundo, ainda mais com dispositivos pessoais móveis e agora com a COVID-19, mas é bastante comum em alguns lugares, como bibliotecas escolares, locais de trabalho, etc.

Na maioria das vezes, o que eles fazem é desligar o computador após o uso. Desligar o computador fecha o navegador, então desligar o computador encerra indiretamente a sessão logada nos aplicativos web.

Quando o próximo funcionário chega para o próximo turno, o computador é ligado novamente e o navegador não conterá mais os cookies baseados em sessão.

Certo, mas também acho que definir isso para um valor como 0 poderia, possivelmente (se não causar muitos problemas de suporte ou for tecnicamente muito difícil), fazer com que o cookie funcione apenas durante a sessão do navegador. Assim, a descrição da configuração do site poderia indicar isso.

idade máxima da sessão [padrão 1440 horas]

O usuário permanecerá logado por n horas desde a última visita. Quando definido como 0, o usuário será desconectado ao fechar o navegador.

Hospitais: Eu só compartilho o que sei que é feito na prática. Concordo que as telas travam rapidamente, mas isso não é um logout do navegador, muito menos do usuário do sistema operacional. Você consegue imaginar o que as pessoas fariam se o computador precisasse fazer login, aplicar políticas, configurar conexões de rede, tudo antes de carregar algum aplicativo para fazer o que médicos e enfermeiros fazem enquanto alguém está morrendo? De forma semelhante, os logins geralmente não são usuário/senha, mas sim crachá mais um PIN curto, pela mesma razão. UMEs, salas cirúrgicas e a maioria dos outros ambientes ainda precisam documentar informações do paciente, então, onde eu trabalhei, isso tem sido consistente em todos os lugares.

Bibliotecas: Existem políticas de reinicialização ao fazer logout e são eficazes desde que os administradores limparem manualmente os caches de tudo na máquina, mas já vi tantos lugares fazerem o contrário (uma das muitas razões pelas quais nunca usei estações de trabalho compartilhadas, de jeito nenhum, nunca, com minhas credenciais). Já vi a mesma configuração infeliz em hotéis e lan houses (ou cafeterias) regularmente, pelo que vale.

Parece estranho para mim que qualquer aplicativo use essa configuração como padrão para todos os usuários em todas as instalações. A segurança não é o foco da maioria das pessoas quando configuram computadores pela primeira vez, e é complexo o suficiente, de modo geral, para ser uma profissão de tempo integral. Aqueles que configuram computadores para o público deveriam saber melhor, mas os navegadores têm o conceito de cookies de sessão para facilitar que desenvolvedores de aplicativos tenham sessões quando for intuitivo para os usuários.

Exigir que os usuários entendam que precisam limpar manualmente os cookies de um site para fazer logout, quando muitos sites tanto expiram a sessão quanto a encerram ao fechar o navegador, parece exigir demais das pessoas. Não permitir a alternativa de forma alguma, de modo que o usuário precise lembrar de usar o link específico de logout do Discourse, torna-se um problema quando os usuários perdem o link por qualquer motivo; de cabeça:

O usuário navega para fora do Discourse seguindo um link.
O usuário navega para fora do Discourse porque usa a aba para ir a outro lugar explicitamente.
O usuário fecha a aba às pressas para ir a uma aula/reunião/etc.
O navegador falha por qualquer motivo.
O implementador de SSO tem SAML para login, mas não sabe que o aplicativo exige logout explícito para encerrar a sessão do aplicativo.

Além disso, dois (2) meses parecem um TEMPO REALMENTE longo para uma persistência de login. Sei que alguns outros sites hoje em dia podem fazer isso, ou até mesmo ser mais longos, mas os usuários geralmente podem controlar isso com as caixas de seleção “Computador público”, o que não se aplica com SSO, ou talvez nem de forma alguma (não sou um guru do Discourse).

Apenas mais algumas reflexões para considerar.

Eu também tenho esse problema e não sei como resolvê-lo.

Obrigado por isso, @codinghorror. Qual seria o processo e os prazos para que isso seja avaliado e implementado?

Não sei, depende de quão tecnicamente difícil é a alteração. @sam, o que você acha da dificuldade do que foi proposto na minha postagem acima?

Acho que isso também seria um recurso legal, pois permitiria que as pessoas soubessem quem está realmente online e quem está apenas ausente.

Precisamos realmente de uma nova configuração de site aqui, pois isso é conceitualmente desacoplado e tornaria o código difícil de entender.

Especificamente, teríamos que adicionar mínimos aqui:

E em alguns outros lugares para garantir que o código continue funcionando.

A configuração que queremos é uma opção discreta do tipo “deslogar automaticamente os usuários quando o navegador for fechado”.

O tempo de sessão ainda se aplica, mesmo que você use cookies de sessão (ou seja, omita o expires).

Então, por exemplo, você poderia dizer:

  1. Se alguém fechar o laptop e depois abri-lo 3 horas depois, você quer que a pessoa esteja deslogada.
  2. Se alguém fechar o Chrome, você quer que a pessoa esteja deslogada.

São preocupações diferentes.

Talvez possamos adicionar persistent_sessions com padrão true? “quando definido como true, a sessão é mantida quando o navegador é fechado”. Essa mudança leva cerca de 20 minutos.

Ok, se uma configuração de site separada for melhor e for uma mudança fácil de 20 minutos, então eu digo: vamos em frente.

Talvez no futuro essa boa ideia possa ser expandida para uma configuração “por usuário” em vez de apenas uma configuração “por site”?

Isso agora é feito como uma configuração por site.

https://review.discourse.org/t/feature-add-support-for-not-persistent-sessions/15171

Parece-me que é realmente uma escolha do administrador. É um recurso de segurança. A longo prazo, podemos considerar uma lista de permissões de endereços IP que contornem a limitação (para que, por exemplo, computadores na rede corporativa permaneçam logados, enquanto computadores externos sejam automaticamente desconectados).

Acredito que, pela natureza desta solicitação, se trata de um recurso por usuário.

Alguns usuários estão em seus computadores em casa ou no escritório e não precisam que um cookie expire; portanto, deve ser uma escolha deles.

Outros usuários podem ser esses “nômades” em cafés usando computadores compartilhados, e eles desejariam que suas sessões expirassem.

A natureza desse recurso é a segurança da conta do usuário, então essa configuração geralmente é implementada como uma opção ou caixa de seleção do usuário ao fazer login.

O vBulletin, por exemplo, já tinha esse recurso nativo (OOTB) há mais de uma década, e ao fazermos o login, bastava marcar uma caixa se “nós, os usuários” desejássemos que nossa sessão persistisse.

A “segurança” refere-se às contas de usuários, então, historicamente, isso tem sido uma configuração por usuário, apenas para informação.

Atualização: Quando o usuário possui uma conta privilegiada (administrador, moderador, líder, etc.), há também a questão maior da segurança geral do site.

Já vi isso implementado em muitos, muitos sites. A implementação típica é:

Manter-me conectado por 30 dias

[ ENTRAR ]

Não tenho certeza de quando chegaremos a isso, mas quando finalmente o fizermos, provavelmente será necessária uma configuração do site para habilitar essa funcionalidade. Existem complicações em relação a onde exibir uma caixa de seleção como essa se logins sociais estiverem habilitados.

Obrigado a todos. Sua ajuda e compreensão são muito apreciadas.

Obrigado.

Sim, logins sociais nunca foram “nosso forte” devido ao rastreamento de comportamento; então, minha perspectiva é muito mais restrita do que sua necessidade muito maior e complexa de dar suporte a redes sociais.

Obrigado pelo excelente trabalho de toda a sua equipe. Bem feito.

Primeiramente: muito obrigado pela correção rápida. No entanto, tenho uma pergunta: seria possível transformar isso em uma configuração por usuário com um padrão específico, para que os usuários possam optar por não participar através de suas preferências?

Isso é exatamente o que foi discutido acima como um trabalho futuro possível, devido ao maior esforço necessário e a alguns problemas desagradáveis de design de interface.

Além disso, queremos deixar o recurso disponível por um tempo para ver se alguém encontra algum problema técnico com a forma como estamos fazendo.