Existem casos que as aplicações web precisam de algumas camadas a mais de segurança. Hoje, eu vim falar sobre o limite de tempo de sessão do usuário.
É muito comum a gente ver essa funcionalidade em aplicações de bancos. Onde, dado um período de inatividade, o sistema desloga o usuário. No sistema escolar da minha universidade também tem um período de sessão máximo (1h30). Após esse período, sua sessão expira.
Qual o objetivo por trás dessa estratégia?
As vezes, pode ser muito perigoso deixar o usuário logado por tempo indeterminado. Principalmente quando o sistema trabalha com dados sensíveis e usado em ambientes públicos.
Imagine a situação de uma seguradora, por exemplo. Os atendentes compartilham dos notebooks dispostos no estabelecimento. João, que estava atendendo um cliente, saiu para o almoço e fechou o navegador, sem clicar em sair do sistema da empresa.
Passado alguns minutos, Carlos, um outro atendente, pegou o notebook para usar, abriu o navegador e acessou o sistema da empresa. Seja qual for o caráter de Carlos, se é uma boa pessoa ou não, não importa. Agora Carlos tem acesso a conta de João. Carlos pode se passar por João e fazer o que bem entender no sistema.
Como implementar limite de sessão por inatividade no Django
O Django é um framework fantástico que eu escolhi para ser minha stack. E, nele, é muito fácil implementar esse limite de tempo na sessão, seja por inatividade ou não.
Tudo o que precisamos fazer é adicionar essa linha no arquivo settings.py:
SESSION_COOKIE_AGE = 1800
A variável SESSION_COOKIE_AGE recebe um valor inteiro que indica a quantidade de segundos que a sessão vai durar. 1800 segundos é equivalente a 30 minutos.
Todas as sessões de usuário irão durar 30 minutos.
Agora, também podemos implementar a lógica de inatividade com essa várivel aqui:
SESSION_SAVE_EVERY_REQUEST = True
O que ela irá fazer, como o próprio nome diz, é salvar toda a requisição do usuário da sessão.
O que isso significa na prática?
Imagine que o João, o primeiro atendente, está navegando no sistema da empresa, quando parou para analisar o relatório. Através da variável SESSION_COOKIE_AGE, sabemos que ele tem 30 minutos de sessão no sistema.
Agora imagine que João ficou 25 minutos lendo o relatório e depois clicou em outra rota dentro do mesmo sistema. Através da variável SESSION_SAVE_EVERY_REQUEST, essa requisição foi salva e o contador, que inicialmente faltava 5 minutos para expirar, agora zerou e ele tem mais 30 minutos para continuar navegando no sistema.
Se em 30 minutos, João não fizer qualquer requisição no sistema da seguradora, sua sessão irá ser destruída. (Agora, no cenário que ele saiu para o almoço, existem grandes chances de quando o Carlos pegar o notebook, a sessão de João já ter expirado).
Explicando um pouco o conceito técnico por trás da funcionalidade
Algumas pessoas, principalmente quem está começando agora, como eu já fui, devem estar se perguntando: "mas ele vai salvar toda a requisição dos usuários!! E se tiver mil usuários simultâneos, como que o Django vai dar conta?".
O que acontece é que o Django não salva no BD todas as requisições dos usuários. Quem vai cuidar disso tudo é o navegador do usuário, através dos cookies de navegação. Tudo o que o Django precisa fazer é mandar um novo cookie, com a data de expiração para 30 minutos no futuro, a cada nova requisição feita no sistema.
O próprio navegador do usuário se encarrega de destruir a sessão. Essa sessão nada mais é que uma variável cookie salva no navegador que você está usando. Por isso que, se você entrar no Instagram pelo Chrome e abrir o Firefox logo em seguida, você não estará logado no Firefox. Porque o Firefox não tem o cookie de login do Instagram.
Foto da capa by Agê Barros on Unsplash