«1. Обзор

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

2. access=“allowAll”

Настройка элемента \u003cintercept-url\u003e с доступом=”allowAll” настроит авторизацию так, чтобы все запросы разрешались по этому конкретному пути: 

<intercept-url pattern="/login*" access="permitAll" />

~~ ~ Или с помощью конфигурации Java: 

http.authorizeRequests().antMatchers("/login*").permitAll();

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

3. filter=†none“

Это функция до 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. security=“none”

Как мы видели в сообщение об ошибке выше, Spring 3.1 заменяет фильтры = «нет» новым выражением — безопасность = «нет».

Область действия также изменилась — она больше не указывается на уровне элемента \u003cintercept-url\u003e. Вместо этого Spring 3.1 позволяет определять несколько элементов \u003chttp\u003e — каждый со своей собственной конфигурацией цепочки фильтров безопасности. Таким образом, новый атрибут безопасности теперь принадлежит элементу \u003chttp\u003e.

На практике это будет выглядеть так: 

<http pattern="/resources/**" security="none"/>

Или с конфигурацией Java: 

web.ignoring().antMatchers("/resources/**");

Вместо старого: также полностью отключите цепочку фильтров безопасности для этого пути запроса — поэтому, когда запрос обрабатывается в приложении, функции Spring Security будут недоступны. 

<intercept-url pattern="/resources/**" filters="none"/>

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

По той же причине нет смысла указывать дополнительные атрибуты для элемента \u003chttp\u003e, который уже настроен с параметром security=“none”, потому что этот путь запроса не защищен, и атрибуты будут просто проигнорированы.

В качестве альтернативы можно использовать access=’IS_AUTHENTICATED_ANONYMOUSLY’, чтобы разрешить анонимный доступ.

5. Предостережения относительно безопасности=“none”

При использовании нескольких элементов \u003chttp\u003e, некоторые из которых настроены с параметром security=“none”, имейте в виду, что порядок, в котором эти элементы определены, важен. Мы хотим, чтобы сначала были определенные пути \u003chttp\u003e, а в самом конце следовал универсальный шаблон.

Также обратите внимание, что если элемент \u003chttp\u003e не определяет шаблон, то по умолчанию он сопоставляется с универсальным шаблоном соответствия — —/** — так что еще раз, этот элемент нужно быть последним. Если порядок элементов неправильный, создание цепочки фильтров безопасности завершится ошибкой:

6. Заключение 

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)

В этой статье обсуждаются варианты разрешения доступа к пути с помощью Spring Security — основное внимание о различиях между фильтрами = «нет», безопасностью = «нет» и доступом = «разрешить все».

Как обычно, примеры доступны на GitHub.

«