Estou com um problema bem complicado, talvez alguem aqui do guj possa me ajudar.
Contextualizando: tenho uma app Java Web com JSF + JBoss Seam, com a autenticação realizada pelo Identity do Seam.
Problema: ao fechar o browser com esta app autenticada, caso o browser esteja configurado para restaurar sessão ao abrir, e o usuário reabre o browser, a app parmanece autenticada, com a última sessão ativa. Normal isso até pq o browser restaura a sessão.
Acontece que o usuário não quer este tipo de comportamento.
Pesquisei algumas soluções mas não achei nada 100%, sempre tem algum porém.
Reparei que em alguns Internet Banking tem alguns tratamentos.
Alguém tem uma dica de como resolver esse problema?
Na minha opinião vc não deveria fazer nada…
Se o navegador do usuário esta configurado para armazenar o cookies com o ID da sessão HTTP mesmo fechando…
Se ele fizer isso dentro do tempo permitido do timetout da sessão, acredito q não existe problema…
Esse é velha historia de vc tentar ficar mirabolando mecanismos fora dos requisitos da sua solução para contornar “limitações e controversas” do protocolo HTTP.
Se ele não quer…é só configurar seu navegador da determinada plataforma para q não o faça…
Tem algumas coisas que da para fazer…mas acho q não esta no escopo da solução…
Eu mesmo me desfio dessas armadilhas…
Cara, concordo tbm, mas é um sistema bancário, e o cliente viu em alguns bancos que há tratamentos, por isso ele quer um “mecanismo” pra tratar e não permitir isso.
Fiz o teste no Santander, foi no Firefox e nele funciona conforme meu usuário espera.
Porém no Santander parece não ser Java, vi que usam alguns iframes e frames, provavelmente não devem usar sessão como no Java.
Antes de tudo…Isso não tem nada haver com Java, uma vez que algo relacionado com o protocolo…
Então vamos conceituar a coisa.
Essa situação é tecnicamente impossível de fazer, justamente pelo fato da protocolo HTTP ser stateless e com isso não mantendo conexão ativa. Foi justamente que toda tecnologia server side tem o timeout da sessão que controla isso.
É possível vc contornar isso, mas com uma serie de problemas sem garantia nenhuma.
As opções para vc fazer se contornar isso são geram mais problemas inerentes aos limitadores:
Não use sessão via cookies e sim via URL - vai gerar um complicador grande no seu projeto caso o codigo não esteje pronto para isso. Passando o cokkies via URL, quando o usuario abrir o navegador ele vai entrar sem o valor do anterior recomeçando a sessão. Entretando se ele fizer bookmark ja era…não vai adiantar…
Implementar uma puta logica JS crossbrowser no beforeunload or unload para enviar um mensagem de timeout ou deleção do cookies na saida da ultima pagina ativa do solução. Os problemas são:
*) como saber qual é a ultima pagina se o usuário pode fechar o navegador em qualquer uma?
*) com vc vai saber que ele ta saindo e pagina indo para outra e não saida da ultima? kkkk Vai rolar um JS nervoso ai com estado dentro do navegador…
*) Qualquer motivador pode fazer o navegador travar e não enviar o pedido de fechamendo, crash na navegador, crash SO, crash HD etc etc…
*) Algumas teclas de atalhos tipo ALT+f4 fecham o navegador mas não disparam o evento do javascript…com fica isso? Alguns podem fazer outros não…não tem como vc testar isso em todos os navegadores existentes hoje…temos navegadores em PC, celulares, smartphones, tables e até TV.
*) Nem todos os navegadores tem a mesma tecla de atalho para fechar o navegador…e ai? como fica?
Vc pode garantir a operação em 2 ou 3 navegadores mais comuns…mas mesmo assim vc não termina com algo robusto…
*) Os eventos beforeunload or unload não são garantidos em todos os navegadores…
E se o usuario se autenticar e foi no banheiro deixando o navegador aberto…nesse tempo alguem operar no sistema!!..vc vai ter que implementar algo para garantir tb??? kkkkk …
Eu acredito que cada cliente habilitado na sua solução deveria assinar um termo jurídico que garanta vc’s não tem como garantir as operações em problemas causados por essa natureza…