Ограничения использования PhaseListener вместо фильтра сервлетов для авторизации
Я в настоящее время использую PhaseListener
как ниже, чтобы выполнить авторизацию пользователя.
private PhaseId phaseId = PhaseId.RESTORE_VIEW;
@Override
public void afterPhase(PhaseEvent event) {
FacesContext fc = event.getFacesContext();
boolean isOnAllowedPage = false;
String[] allowedPages = choseRightPages(); // chose pages for role
for (String s : allowedPages) {
if (fc.getViewRoot().getViewId().lastIndexOf(s) > -1) {
isOnAllowedPage = true;
break;
}
}
if (!isOnAllowedPage) {
NavigationHandler nh = fc.getApplication().getNavigationHandler();
nh.handleNavigation(fc, null, "prohibited");
}
}
Он делает то, что я хочу, однако я не вижу его в списке Как обрабатывать аутентификацию / авторизацию с пользователями в базе данных? и эта тема Coderanch под названием "авторизация с проблемой фазселистера" также упоминает следующее:
Вы не должны связывать авторизацию так тесно с JSF. Лучше использовать управляемую контейнером аутентификацию и / или простой фильтр, действующий по URL-шаблону, охватывающему защищенные страницы.
Я не совсем понимаю ограничения использования PhaseListener
вместо Filter
при выполнении авторизации пользователя. Может кто-нибудь объяснить это мне?
1 ответ
PhaseListener
запускается только по запросу JSF (т. е. по запросу HTTP, который вызвал FacesServlet
). Он не запускается при выполнении запроса не-JSF и, таким образом, представляет потенциальную утечку безопасности для запросов не-JSF. Сервлет Filter
может быть запущен при каждом запросе HTTP, независимо от целевого сервлета.
Другими словами: авторизация HTTP-запроса не должна быть связана с наличием FacesContext
доступно, но для ServletRequest
имеется в наличии. Всегда старайтесь авторизоваться как можно ниже.