2012-01-18 3 views
1

У меня есть метод, который обрабатывает запрос с URI «/ home». Этот запрос создается при успешной процедуре входа в систему. Вот немного кода, чтобы поддержать мою ситуацию:Spring MVC странное поведение

<security:form-login login-processing-url="/static/j_spring_security_check" 
login-page="/login" authentication-failure-url="/login?login_error=t" 
default-target-url="/home"/> 

Тело метод демонстрирует то, что я пытаюсь достичь:

String userMail = SecurityContextHolder.getContext(). 
    getAuthentication().getName(); 
logger.info(userMail); 

Person p = userService.retrieveUserByEmail(userMail); 
session.setAttribute("person", p); 

return "user/home"; 

Этот бит имеет важное значение, поскольку человек р используется в качестве источника данных для других Запросы.

Теперь проблема. Я не знаю, является ли это собственностью Google Chrome, но по какой-то причине браузер запоминает запрос, который вы выполнили перед входом в систему, и вместо того, чтобы проходить через/home запрос после успешной процедуры входа в систему, он генерирует предыдущий запрос в обход этого/home gate, что приводит к исключению нулевого указателя, поскольку человек p никогда не был настроен, поскольку сеанс не был заполнен/home-запросом.

Я знаю, что для других запросов я должен сделать валидацию, но мне не нравится идея разрешить пользователю генерировать любой запрос без предварительного прохождения/home.

Сделано с текстовым описанием и теперь, чтобы объяснить, как я получаю нежелательное поведение пошагово:

  1. задать для запроса, что вы знаете, существуют такие, как: MYAPP/nameOfSomething/viewThisSomething - вы принесли в протоколирование в странице, как ожидается, (вы должны пройти проверку подлинности для запроса, чтобы быть принятым)

  2. вы вводите правильные учетные данные, и вместо того, чтобы идти по умолчанию-целевой объект URL = «/ домашний» вы автоматически делаете предыдущий запрос MYAPP/nameOfSomething/viewThisSomething без заполнения sessio n с необходимыми данными и результатом является исключение nullpointer.

Что еще интересно, что регистратор показывает почту, так что это может быть, что они оба выполнены одновременно, но/дом запрос медленнее - это может произойти?

Я разрешаю ситуацию другим способом, проверяя, является ли null и вынуждает вернуться в/home, который работает так, как ожидалось, но я контролирую урод и не люблю, когда пользователь делает то, что он не собирается делать.

Благодарим Вас за время,

ответ

2

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

От http://static.springsource.org/spring-security/site/docs/3.1.x/reference/springsecurity-single.html#ns-form-target:

Если форма Логин не запрашивается при попытке получить доступ к защищенному ресурсу , опция по умолчанию-целевой URL входит в игру. Это URL-адрес , по которому пользователь будет отправлен после успешного входа в систему, а по умолчанию - «/».Вы также можете настроить так, чтобы пользователь всегда попадал на эту страницу (независимо от того, был ли вход в систему «по требованию» или они явно решили войти в систему), установив атрибут «Всегда использовать-по умолчанию-цель» "true"

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

Вы можете сделать это легко, используя собственный подкласс UserPasswordAuthenticationFilter, который устанавливает соответствующий атрибут в сеансе после успешной аутентификации.

+0

О, я так плохо разбираюсь в обычае, но в любом случае спасибо, что посмотрю. – Aubergine