Как изменить исходную запрошенную страницу, используемую j_security_check?

Когда неавторизованный пользователь запрашивает некоторые ресурсы, он будет перенаправлен на страницу входа, но j_security_check сохранит исходный запрошенный ресурс. Если пользователь успешно войдет в систему, он будет перенаправлен на этот ресурс.

Проблема в том, что иногда запрошенный ресурс является динамическим, поэтому он может не существовать. В моем приложении есть много мест с таким поведением, поэтому вместо проверки этого в каждом «обработчике ресурсов» (контроллере) мы пытаемся централизовать всю эту логику в фильтре, который перехватывает j_security_check переадресацию на страницу входа.

Теперь, как мы можем получить исходный запрошенный ресурс, сохраненный механизмом проверки подлинности на основе форм? Это зависит от поставщика?

Еще один вариант:

Если я могу запустить фильтр ПЕРЕД j_security_check, я не могу изменить URL-адрес, но я могу отправить пользователю перенаправление с «действительным URL-адресом». Но как я могу выполнить фильтр перед j_security_check?


person ggarciao    schedule 30.08.2011    source источник


Ответы (2)


Если страницы являются динамическими и «могут не существовать», но ссылка могла быть действительной в какой-то момент времени, а ваше приложение отказывается от этого старого запроса, то в вашем приложении что-то не работает. Если «динамические страницы» на самом деле являются просто сопоставлением шаблонов с использованием переменных пути, тогда ваш код должен реагировать на такие ситуации, поскольку каждый запрос страницы должен обрабатываться соответствующим образом.

Пример: у меня есть страница для отображения общедоступного профиля пользователя. Может быть, пользователь отменяет регистрацию на моем сайте. Теперь «страница» не должна «существовать». Например, в Spring я бы использовал PathVariable и сделал свой обработчик реагирующим на существование или отсутствие пользователя:

@RequestMapping(value="/display/{userkey}")
public String displayUser (@PathVariable("userkey") String userkey) {
    User user = someDAO.getUser(userkey);
    if(user != null) {
        // do something
    } else {
        // do something else
    }
    return "theView";
}

В этом случае я бы вернул браузеру какое-то значимое сообщение или, возможно, перенаправил бы его в другое место. Кажется, это не столько проблема безопасности, сколько дизайн приложения.

person atrain    schedule 30.08.2011
comment
Это ресурсы: файлы, такие как изображения, PDF-файлы и т. д. (это CMS). Как я уже сказал, у нас есть один контроллер для каждого типа ресурсов. Но у нас их так много, что мы пытаемся централизовать эту логику в одном фильтре. Я знаю, что для этого мы можем добавить фронт-контроллер с сервисом в воркер, но с фильтром мы можем добавить эту функцию, не меняя какой-либо модуль (фильтр перехвата). Возможно, мы что-то упустили в дизайне, поэтому я создам отдельную тему, чтобы обсудить это, но даже с архитектурным решением мне было интересно знать, как работать с j_security_check :-D - person ggarciao; 31.08.2011

Вот что вам нужно сделать:

  1. Создайте фильтр для j_security_check в файле web.xml.
  2. В своем фильтре перед chain.doFilter(...) измените содержимое файла cookie с именем WASReqURL, чтобы перенаправить на сервлет, который будет после успешного входа в систему.
person Hesham Yassin    schedule 18.06.2018