Você pode e não deve desabilitar o botão Voltar ou o histórico do navegador. Isso é ruim para a experiência do usuário. Existem hacks de JavaScript, mas eles não são confiáveis e também não funcionarão quando o cliente tiver o JS desativado.
Seu problema concreto é que a página solicitada foi carregada do cache do navegador em vez de diretamente do servidor. Isso é essencialmente inofensivo, mas confuso para o usuário final, porque ele / ela pensa incorretamente que está realmente vindo do servidor.
Você só precisa instruir o navegador a não armazenar em cache todas as páginas JSP restritas (e, portanto, não apenas a página / ação de logout em si!). Desta forma, o navegador é forçado a solicitar a página do servidor em vez de do cache e, portanto, todas as verificações de login no servidor serão executadas. Você pode fazer isso usando um filtro que define os cabeçalhos de resposta necessários no doFilter()
método:
@WebFilter
public class NoCacheFilter implements Filter {
@Override
public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain) throws IOException, ServletException {
HttpServletResponse response = (HttpServletResponse) res;
response.setHeader("Cache-Control", "no-cache, no-store, must-revalidate"); // HTTP 1.1.
response.setHeader("Pragma", "no-cache"); // HTTP 1.0.
response.setDateHeader("Expires", 0); // Proxies.
chain.doFilter(req, res);
}
// ...
}
Mapeie isso Filter
em um url-pattern
de interesse, por exemplo *.jsp
.
@WebFilter("*.jsp")
Ou se você deseja colocar essa restrição apenas em páginas seguras, você deve especificar um padrão de URL que cubra todas essas páginas seguras. Por exemplo, quando eles estão todos na pasta /app
, você precisa especificar o padrão de URL de /app/*
.
@WebFilter("/app/*")
Além disso, você pode fazer esse trabalho da mesma Filter
forma que verifica a presença do usuário conectado.
Não se esqueça de limpar o cache do navegador antes de testar! ;)
Veja também: