Faça acessos antigos pararem na hora certa

Imagine uma cliente usando um computador compartilhado, uma pessoa deixando o notebook sobre a mesa ou um celular desaparecendo. O app pode continuar reconhecendo quem entrou mesmo depois que essa pessoa vai embora. Isso é prático porque ninguém precisa digitar a senha em cada página, mas pode deixar endereços, mensagens, dados de pagamento ou registros da empresa visíveis para quem pegar o aparelho. Decida o que deve acontecer depois de sair, fechar o navegador, passar muito tempo sem usar, trocar a senha ou remover alguém da equipe.

Crie uma conta que tenha apenas nomes e informações inventadas. Abra essa conta no celular e no computador, ou em dois navegadores diferentes, e escreva o resultado esperado antes de cada verificação. O nome técnico do acesso temporário que o app lembra é sessão. Uma sessão significa apenas que o app aceita que aquele navegador já confirmou quem está usando a conta. Você não precisa saber como isso funciona por dentro. Precisa somente confirmar que o app deixa de aceitar esse acesso em todos os momentos definidos nas suas regras.

Entre com a conta de teste em duas abas. Nas duas, abra páginas com dados da conta, informações de clientes, mensagens ou configurações. Use o botão normal de sair em uma aba. Volte à outra, atualize cada página e tente uma ação sem risco, como mudar o nome de exibição da conta de teste. O app deve pedir a senha novamente antes de mostrar informações atuais ou aceitar uma alteração. Aperte também o botão Voltar do navegador. Uma página antiga pode aparecer por causa da memória de curto prazo do navegador, mas não deve carregar informações novas nem permitir outra ação.

Repita a verificação em dois navegadores ou aparelhos separados. Seu app pode manter o segundo aparelho conectado depois de uma saída comum, mas essa escolha precisa ficar clara para as pessoas. Se houver a opção “sair de todos os aparelhos”, cada navegador antigo deve parar de funcionar. O nome técnico para fazer um acesso antes aceito deixar de valer é invalidação de sessão. Confira o resultado visível em vez de confiar apenas no botão: atualize uma página antiga, abra uma área restrita à conta e tente uma mudança sem risco. Registre quais aparelhos pararam e quais continuaram ativos.

As pessoas deixam o navegador aberto enquanto atendem uma ligação, almoçam, compartilham um computador ou encerram o expediente. Escolha por quanto tempo o app pode ficar sem uso antes de pedir que a pessoa entre novamente. Tome a decisão conforme o que a conta mostra ou permite fazer. Uma página com conteúdo público pode ficar disponível por mais tempo que uma conta com endereços, anotações de saúde, registros de funcionários, dados de pagamento ou comandos capazes de gastar dinheiro. Escreva o período escolhido e o motivo em linguagem simples para uma mudança futura não substituir sua decisão sem aviso.

Teste a regra em vez de olhar apenas sua configuração. Entre com a conta de teste, deixe o app completamente parado pelo período escolhido, atualize uma página e tente uma alteração sem risco. O nome técnico para encerrar o acesso lembrado depois de certo tempo é expiração de sessão. O app deve explicar claramente que é preciso entrar outra vez. Teste também o uso ativo perto desse limite. Quem ainda estiver digitando pode receber um aviso útil, e textos inacabados que não contenham informações sensíveis podem ser preservados quando isso for seguro. Uma aba esquecida não deve manter informações de clientes disponíveis para sempre.

Use a conta de teste para ensaiar a perda de um aparelho. Entre em dois dispositivos, troque a senha em um deles e volte ao outro. Atualize as páginas da conta e tente uma ação sem risco. Decida se a troca de senha deve encerrar imediatamente todos os outros acessos lembrados; em apps que guardam informações de clientes ou permitem pagamentos, essa costuma ser a escolha mais segura. Repita a verificação depois de usar o processo de recuperação da conta. Uma senha nova não resolve o problema se o navegador perdido ainda consegue abrir registros atuais sem nova confirmação.

Em seguida, desative o usuário de teste ou remova sua permissão na equipe enquanto outro navegador continua aberto. Esse navegador deve perder rapidamente as ações que foram retiradas. O nome técnico para retirar um acesso que antes era aceito é revogação. Registre quem pode remover uma pessoa, responder à perda de aparelho e confirmar o resultado. Senhas, chaves de pagamento e códigos de acesso que abrem informações ou permitem gastar dinheiro devem ficar na parte protegida em que o app realiza tarefas de confiança, nunca em arquivos enviados ao navegador do visitante. Se o app expuser esses itens, encerrar acessos antigos não será suficiente para protegê-los.

Repita todos os testes quando mudar as telas de entrada, configurações da conta, permissões da equipe, memória do navegador, hospedagem ou serviço que guarda informações de clientes. Uma alteração visual pode preservar uma página antiga por engano, e uma função criada para facilitar o uso pode prolongar o acesso lembrado sem deixar isso evidente. Mantenha um registro curto com a data, o nome dado à versão atual do app, os navegadores ou aparelhos usados, o resultado esperado e o resultado encontrado. Um registro repetível ajuda a perceber mudanças e oferece ao seu construtor com IA uma falha concreta para investigar.

Inclua uma visão externa nessa rotina, mas entenda seu limite. O VibeCodeWall verifica o app público por fora e acompanha mudanças importantes ao longo do tempo. Ele não precisa ver código privado para apontar alterações públicas que merecem revisão. Essa verificação externa não consegue entrar como seu cliente de teste nem confirmar o que um navegador antigo ainda pode fazer. Continue realizando seus próprios testes de conta em dois aparelhos. O acompanhamento externo contínuo e os testes repetidos com uma conta de teste ajudam você a revisar mudanças futuras antes que informações reais de clientes sejam afetadas.