Ответ 1
Вы можете и не должны отключать кнопку назад или историю браузера. Это плохо для пользователей. Есть 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
, что и там, где вы проверяете наличие зарегистрированного пользователя.
Не забудьте очистить кеш браузера перед тестированием!;)