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

Question

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

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

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

Другой вариант:

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

Answer 1

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

Пример: У меня есть страница для отображения общедоступного профиля пользователя. Возможно, пользователь отменил мой сайт. Теперь «страница» не должна «существовать». Весной, например, я хотел бы использовать 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"; 
} 

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