Puoi e non devi disabilitare il pulsante Indietro o la cronologia del browser. È un male per l'esperienza dell'utente. Esistono hack JavaScript, ma non sono affidabili e non funzioneranno nemmeno quando il client ha JS disabilitato.
Il tuo problema concreto è che la pagina richiesta è stata caricata dalla cache del browser invece che direttamente dal server. Questo è essenzialmente innocuo, ma in effetti confonde l'utente finale, perché pensa erroneamente che provenga davvero dal server.
Devi solo istruire il browser a non memorizzare nella cache tutte le pagine JSP limitate (e quindi non solo la pagina / azione di logout stessa!). In questo modo il browser è costretto a richiedere la pagina dal server invece che dalla cache e quindi verranno eseguiti tutti i controlli di login sul server. Puoi farlo utilizzando un filtro che imposta le intestazioni di risposta necessarie nel doFilter()
metodo:
@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);
}
// ...
}
Mappa questo Filter
su un url-pattern
interesse, per esempio *.jsp
.
@WebFilter("*.jsp")
Oppure, se si desidera applicare questa restrizione solo alle pagine protette, è necessario specificare un pattern URL che copra tutte quelle pagine protette. Ad esempio, quando sono tutti nella cartella /app
, è necessario specificare il pattern URL di /app/*
.
@WebFilter("/app/*")
Inoltre, puoi fare questo lavoro nello stesso modo Filter
in cui stai controllando la presenza dell'utente connesso.
Non dimenticare di svuotare la cache del browser prima di eseguire il test! ;)
Guarda anche: