Вы можете и не должны отключить кнопку браузера назад или историю.Это плохо для пользовательского опыта.Есть хаки JavaScript, но они ненадежны и также не будут работать, если у клиента отключен JS.
Ваша конкретная проблема заключается в том, что запрашиваемая страница загружается из кэша браузера, а не прямо с сервера.Это по сути безвредно, но действительно вводит в заблуждение конечного пользователя, потому что он / она неправильно думает, что это действительно исходит от сервера.
Вам просто нужно указать браузеру , а не кеш все ограниченные страницы JSP (и, следовательно, не только страница выхода из системы / само действие!).Таким образом, браузер вынужден запрашивать страницу с сервера, а не из кэша, и, следовательно, будут выполняться все проверки входа в систему на сервере.Вы можете сделать это, используя Filter , который устанавливает необходимые заголовки ответа в методе doFilter()
:
@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);
}
// ...
}
Сопоставьте это Filter
с url-pattern
интерес, например *.jsp
.
@WebFilter("*.jsp")
Или, если вы хотите наложить это ограничение только на защищенные страницы, вам следует указать шаблон URL, который охватывает все эти защищенные страницы.Например, когда все они находятся в папке /app
, необходимо указать шаблон URL-адреса /app/*
.
@WebFilter("/app/*")
Более того, вы можете выполнять эту работу в том же Filter
, что и при проверке присутствия вошедшего в систему пользователя.
Не забудьте очиститькеш браузера перед тестированием!;)
См. Также: