.and().formLogin()
.loginPage("/login")
.defaultSuccessUrl("/design")
Как настроено здесь, если пользователь должен был успешно войти в систему после прямого перехода на страницу входа, он будет перенаправлен на страницу / design.
При желании вы можете принудительно заставить пользователя перейти на страницу design после входа в систему, даже если он находился на другой странце до входа в систему, передав значение true в качестве второго параметра в defaultSuccessUrclass="underline"
.and().formLogin()
.loginPage("/login")
.defaultSuccessUrl("/design", true)
Теперь, когда вы имеете дело с пользовательской страницей входа, давайте перейдем на другую сторону монеты аутентификации и посмотрим, как вы можете позволить пользователю выйти из системы.
4.3.3 Выход из системы
Выход из системы так же важен, как и вход в приложение. Чтобы выйти, -вам просто нужно вызвать logout для объекта HttpSecurity:
.and().logout()
.logoutSuccessUrl("/")
Это настраивает фильтр безопасности, который перехватывает запросы POST для /logout. Поэтому, чтобы обеспечить возможность выхода из системы, вам просто нужно добавить форму и кнопку выхода из системы в представлениях вашего приложения:
<form method="POST" th:action="@{/logout}">
<input type="submit" value="Logout"/>
</form>
Когда пользователь нажимает кнопку, его сеанс очищается, и он выходит из приложения. По умолчанию он будет перенаправлен на страницу входа, где сможет снова войти в систему. Но если вы хотите, чтобы он был отправлен на другую страницу, вы можете вызвать logoutSucessFilter (), чтобы указать другую целевую страницу после выхода:
.and().logout()
.logoutSuccessUrl("/")
В этом случае, пользователи будут отправлены на главную страницу после выхода.
4.3.4 Предотвращение подделки межсайтовых запросов
Подделка межсайтовых запросов (CSRF) является обычной атакой безопасности. Он включает в себя предоставление пользователю кода на злонамеренно разработанной веб-странице, которая автоматически (и обычно тайно) отправляет форму другому приложению от имени пользователя, который часто является жертвой атаки. Например, пользователю может быть представлена форма на веб-сайте злоумышленника, которая автоматически публикует URL-адрес на банковском веб-сайте пользователя (который предположительно плохо спроектирован и уязвим для такой атаки) для перевода денег. Пользователь может даже не знать, что атака произошла, пока не заметит пропажу денег со своего счета.
Для защиты от таких атак приложения могут создать токен CSRF при отображении формы, поместить этот токен в скрытое поле, а затем хранить его для последующего использования на сервере. После отправки формы токен отправляется обратно на сервер вместе с остальными данными формы. Затем запрос перехватывается сервером и сравнивается с первоначально созданным токеном. Если токены совпадают, запрос разрешается обработать. В противном случае форма должна быть отрисована вредоносным веб-сайтом без знания токена, сгенерированного сервером.
К счастью, Spring Security имеет встроенную защиту CSRF. Еще более удачным является то, что она включена по умолчанию, и вам не нужно явно настраивать её. Необходимо только убедиться, что все формы, отправляемые приложением, содержат поле с именем _csrf, содержащее токен CSRF.
Spring Security даже упрощает это, помещая токен CSRF в атрибут запроса с именем _csrf. Таким образом можно отобразить токен CSRF в скрытом поле в шаблоне Thymeleaf:
<input type="hidden" name="_csrf" th:value="${_csrf.token}"/>
Если вы используете библиотеку тегов Spring MVC’s JSP или Thymeleaf с Spring Security dialect, вам даже не нужно явно создавать скрытое поле. Скрытое поле будет создано автоматически.
В Thymeleaf, вам просто нужно убедиться, что один из атрибутов элемента <form> с префиксом в качестве атрибута Thymeleaf. Это обычно не проблема, так как довольно часто Thymeleaf отображает путь как относительный контекст. Например, атрибут th:action-это все, что вам нужно для отображения скрытого поля Thymeleaf:
<form method="POST" th:action="@{/login}" id="loginForm">
Можно отключить поддержку CSRF, но я не решаюсь показать вам, как это сделать. CSRF-защита важна и легко обрабатывается в формах, поэтому нет причин ее отключать. Но если вы настаиваете на его отключении, вы можете сделать это, вызвав disable() следующим образом:
.and().csrf().disable()
Опять же, я предупреждаю вас не отключать защиту CSRF, особенно для производственных приложений.
Вся ваша безопасность веб-уровня теперь настроена для Taco Cloud. Помимо прочего, теперь у вас есть настраиваемая страница входа и возможность аутентификации пользователей в репозитории пользователей с поддержкой JPA. Теперь давайте посмотрим, как можно получить информацию о зарегистрированных пользователей.