http.authorizeRequests()
.antMatchers("/design", "/orders")
.hasRole("ROLE_USER")
.antMatchers(“/”, "/**").permitAll();
}
Вызов метода AuthorizationRequests() возвращает объект (ExpressionInterceptUrlRegistry), в котором можно указать URL-пути, шаблоны и требования безопасности для этих путей. В этом случае необходимо указать два правила безопасности:
-Запросы /design и /orders должны быть доступны для пользователей с предоставленными полномочиями ROLE_USER.
-Все запросы должны быть разрешены всем пользователям.
Порядок этих правил важен. Правила безопасности, объявленные первыми, имеют приоритет над правилами, объявленными ниже. Если бы вы поменяли порядок этих двух правил безопасности, все запросы имели бы permitAll(), примененный к ним; правило для /design и /orders запросов не имело бы никакого эффекта.
Методы hasRole() и allowAll() - это всего лишь несколько методов объявления требований безопасности для путей запросов. Таблица 4.1 описывает все доступные методы.
Табл. 4.1 Методы настройки для определения способа защиты пути
Метод
Описание
access(String)
Разрешает доступ, если данное выражение SpEL имеет значение true
anonymous()
Разрешает доступ анонимным пользователям
authenticated()
Разрешает доступ аутентифицированным пользователям
denyAll()
Безоговорочно запрещает доступ
fullyAuthenticated()
Разрешает доступ, если пользователь полностью аутентифицирован (не запоминается)
hasAnyAuthority(String...)
Разрешает доступ, если у пользователя есть какие-либо из указанных полномочий
hasAnyRole(String...)
Разрешает доступ, если пользователь имеет любую из указанных ролей
hasAuthority(String)
Разрешает доступ, если пользователь имеет полномочия
hasIpAddress(String)
Разрешает доступ, если запрос поступает с указанного IP-адреса
hasRole(String)
Разрешает доступ, если пользователь имеет данную роль
not()
Отрицает эффект любого другого метода доступа
permitAll()
Разрешает безоговорочный доступ
rememberMe()
Разрешает доступ пользователям, прошедшим проверку подлинности с помощью remember-me (запомни меня)
Большинство методов, описанных в табл. 4.1, предоставляют основные правила безопасности для обработки запросов, но они являются самоограничивающимися и разрешают только правила безопасности, определенные этими методами. Кроме того, можно использовать метод access() для предоставления выражения SpEL для объявления расширенных правил безопасности. Spring Security расширяет SpEL, чтобы включить несколько определенных для безопасности значений и функций, как указано в таблице 4.2.
Таблица 4.2 Spring Security расширения Spring Expression Language
Выражение безопасности
Возвращаемое значение
authentication
Объект проверки подлинности пользователя
denyAll
Всегда имеет значение false
hasAnyRole(list of roles)
true, если пользователь имеет любую из заданных ролей
hasRole(role)
true, если пользователь имеет заданную роль
hasIpAddress(IP address)
true, если запрос пришел с заданого IP-адреса
isAnonymous()
true, если пользователь является анонимным
isAuthenticated()
true, если пользователь прошел проверку подлинности
isFullyAuthenticated()
true, если пользователь полностью аутентифицирован (не включая аутентификацию с remember-me (запомни меня))
isRememberMe()
true, если пользователь прошел аутентификацию через remember-me (запомни меня)
permitAll
Всегда принимает значение true
principal
Основной объект пользователя
Как вы можете видеть, большинство расширений выражений безопасности в таблице 4.2 соответствуют аналогичным методам в таблице 4.1. На самом деле, используя метод access() вместе с выражениями hasRole() и permitAll, вы можете переписать configure() следующим образом.
Листинг 4.9 Использование выражений Spring для определения правил авторизации
@Override
protected void configure(HttpSecurity http) throws Exception {
http.authorizeRequests()
.antMatchers("/design", "/orders")
.access("hasRole('ROLE_USER')")
.antMatchers(“/”, "/**").access("permitAll");
}
Сначала это может показаться не таким уж большим делом. В конце концов, эти выражения отражают только то, что вы уже сделали с вызовами методов. Но выражения могут быть гораздо более гибкими. Например, предположите, что (по какой-то сумасшедшей причине) вы только хотели позволить пользователям с полномочиями ROLE_USER создавать новые тако в вторникам (например, Taco Tuesday); вы могли переписать выражение как показано в этой модифицированной версии configure():
@Override
protected void configure(HttpSecurity http) throws Exception {
http.authorizeRequests()