j_security_check не перенаправляет на страницу приветствия - успешный слушатель события входа в систему?

Целую вечность я ломал голову над тем, почему после входа в систему я иногда не обращаюсь к странице приветствия приложения. Я наконец понял это (годы спустя после всех остальных):

  • Я успешно захожу через j_security_check и захожу на страницу приветствия

  • дождитесь окончания сеанса

  • нажмите на ссылку h: которая отправляет запрос GET

  • потому что это GET, а не POST, мой пользовательский ViewExpiredException
    обработчик не пинает

  • контейнер безопасности перенаправляет на страницу входа в систему, потому что сеанс
    истекло время ожидания Из-за тайм-аута сеанса + безопасности контейнера запрос get (из h:link) не виден приложением ни в обработчике фаз, ни в фильтре.

  • Я снова успешно вошел в систему

  • j_security_check перенаправляет меня на страницу, которая вызвала
    аутентификация, в этом случае цель запроса GET.

Последний бит, который я не понял, я предполагал, что он всегда будет идти на страницу приветствия.

Моя проблема в том, что мой текущий дизайн требует, чтобы после входа в систему я всегда показывал страницу приветствия. Страница приветствия имеет событие preRenderView, которое устанавливает некоторую контекстную информацию в bean-объекте сессионной области после входа в систему и увеличивает несколько счетчиков и т. Д.

Эта контекстная информация требуется для поддержки кода компонента для других страниц, и в настоящее время, если я сначала не перейду к странице приветствия, возникнет исключение.

С точки зрения исправления я рассмотрел следующие варианты:

  1. В идеале мог бы быть вызван метод @PostLogin, который бы решал все мои проблемы. Я использую JSF (Mojarra) с CODI Myfaces, но я не вижу ничего, что делает то, что я хочу.

  2. Я мог бы добавить еще немного кода в свой фильтр, но мне нужно сохранить некоторые данные (например, количество логинов), это не выглядит хорошим вариантом. Может я не прав.

  3. Я заставляю все методы preRenderView потенциальных целей j_security_check (страницы, вызываемые с помощью GET) обрабатывать случай, когда они вызываются непосредственно из j_seecurity_check. Я вижу, что это то, что я должен сделать, но это кажется большой проблемой.

  4. Напишите модуль проверки подлинности сервера для glassfish, чтобы переопределить поведение j_security_check.

Как это обычно обрабатывается? Я начал решать эту проблему после перехода на GET для простых случаев навигации после нескольких лет злоупотребления POST, и пользовательский обработчик исключений не работает. Если у кого-нибудь есть какие-либо рекомендации по этому вопросу, я буду признателен, по крайней мере, я знаю, что происходит сейчас. Надеюсь, я что-то упустил очевидное!

Спасибо O/S

1 ответ

Решение

В идеале мог бы быть вызван метод @PostLogin, который бы решал все мои проблемы. Я использую JSF (Mojarra) с CODI Myfaces, но я не вижу ничего, что делает то, что я хочу.

Там действительно нет такой вещи.


Я мог бы добавить еще немного кода в свой фильтр, но мне нужно сохранить некоторые данные (например, количество логинов), это не выглядит хорошим вариантом. Может я не прав.

Это действительно самый простой способ. В принципе:

UserPrincipal user = request.getUserPrincipal();
HttpSession session = request.getSession();

if (user != null && session.getAttribute("user") == null) {
    session.setAttribute("user", user);

    // First-time login. You can do your intercepting thing here.
    response.sendRedirect(request.getContextPath() + "/welcome.xhtml");
}

Я заставляю все методы preRenderView потенциальных целей j_security_check (страницы, вызываемые с помощью GET) обрабатывать случай, когда они вызываются непосредственно из j_seecurity_check. Я вижу, что это то, что я должен сделать, но это кажется большой проблемой.

Это не СУХОЙ.


Напишите модуль проверки подлинности сервера для glassfish, чтобы переопределить поведение j_security_check.

Не могу ответить, потому что я никогда этого не делал.

Другие вопросы по тегам