1. Обзор
Spring Security предоставляет несколько механизмов для настройки шаблона запроса как незащищенного или разрешающего полный доступ. В зависимости от каждого из этих механизмов это может означать либо вообще не запускать цепочку фильтров безопасности на этом пути, либо запускать цепочку фильтров и разрешать доступ.
2. доступ = «разрешить все»
Настройка элемента <intercept-url> с доступом = «permitAll» настроит авторизацию так, чтобы все запросы были разрешены по этому конкретному пути:
<intercept-url pattern="/login*" access="permitAll" />
Или через конфигурацию Java:
http.authorizeRequests().antMatchers("/login*").permitAll();
Это достигается без отключения фильтров безопасности — они все еще работают, поэтому любые функции, связанные с Spring Security, будут по-прежнему доступны.
3. фильтры = «нет»
Это функция до Spring 3.1, которая устарела и заменена в Spring 3.1.
Атрибут filter полностью отключает цепочку фильтров Spring Security на этом конкретном пути запроса :
<intercept-url pattern="/login*" filters="none" />
Это может вызвать проблемы, когда для обработки запроса потребуются некоторые функции Spring Security.
Поскольку это устаревшая функция версий Spring новее 3.0, ее использование с Spring 3.1 приведет к исключению времени выполнения при запуске:
SEVERE: Context initialization failed
org.springframework.beans.factory.parsing.BeanDefinitionParsingException:
Configuration problem: The use of "filters='none'" is no longer supported.
Please define a separate <http> element for the pattern you want to exclude
and use the attribute "security='none'".
Offending resource: class path resource [webSecurityConfig.xml]
at o.s.b.f.p.FailFastProblemReporter.error(FailFastProblemReporter.java:68)
4. безопасность = «нет»
Как мы видели в сообщении об ошибке выше, Spring 3.1 заменяет filter="none" новым выражением — security="none" .
Область действия также изменилась — она больше не указывается на уровне элемента <intercept-url> . Вместо этого Spring 3.1 позволяет определять несколько элементов <http> — каждый со своей собственной конфигурацией цепочки фильтров безопасности. Таким образом, новый атрибут безопасности теперь принадлежит элементу <http> .
На практике это будет выглядеть так:
<http pattern="/resources/**" security="none"/>
Или с конфигурацией Java:
web.ignoring().antMatchers("/resources/**");
Вместо старого:
<intercept-url pattern="/resources/**" filters="none"/>
Подобно filter =”none” , это также полностью отключит цепочку фильтров безопасности для этого пути запроса, поэтому, когда запрос обрабатывается в приложении, функции Spring Security будут недоступны.
Это не проблема для приведенных выше примеров, которые в основном имеют дело с обслуживанием статических ресурсов , где фактическая обработка не происходит. Однако, если запрос каким-либо образом обрабатывается программно, тогда функции безопасности, такие как require-channel , доступ к текущему пользователю или вызов защищенных методов, будут недоступны.
По той же причине нет смысла указывать дополнительные атрибуты для элемента <http> , который уже настроен с параметром security=”none” , поскольку этот путь запроса не защищен, и атрибуты будут просто проигнорированы.
В качестве альтернативы можно использовать access='IS_AUTHENTICATED_ANONYMOUSLY' , чтобы разрешить анонимный доступ.
5. Предостережения по безопасности = «нет»
При использовании нескольких элементов <http> , некоторые из которых настроены с параметром security=”none” , имейте в виду, что порядок, в котором эти элементы определены, важен. Мы хотим, чтобы сначала были определенные пути <http> , а в самом конце следовал универсальный шаблон.
Также обратите внимание, что если в элементе <http> не указан шаблон , то по умолчанию он сопоставляется с универсальным шаблоном соответствия — «/» — поэтому, опять же, этот элемент должен быть последним. Если порядок элементов неправильный, создание цепочки фильтров безопасности не удастся** :
Caused by: java.lang.IllegalArgumentException: A universal match pattern ('/**')
is defined before other patterns in the filter chain, causing them to be ignored.
Please check the ordering in your <security:http> namespace or FilterChainProxy bean configuration
at o.s.s.c.h.DefaultFilterChainValidator.checkPathOrder(DefaultFilterChainValidator.java:49)
at o.s.s.c.h.DefaultFilterChainValidator.validate(DefaultFilterChainValidator.java:39)
6. Заключение
В этой статье обсуждаются варианты разрешения доступа к пути с помощью Spring Security — с акцентом на различия между filter="none", security="none" и access="permitAll" .
Как обычно, примеры доступны на GitHub .