Ответ 1
Ваш пример означает, что Spring (Web) Security игнорирует шаблоны URL, которые соответствуют выражению, которое вы определили ("/static/**")
. Этот URL пропускается Spring Security, поэтому не защищен.
Позволяет добавлять экземпляры RequestMatcher, которые Spring Security должен игнорировать. Веб-безопасность, предоставляемая Spring Security (включая SecurityContext), не будет доступна для соответствующего запроса HttpServletRequest. Как правило, зарегистрированные запросы должны относиться только к статическим ресурсам. Для запросов, которые являются динамическими, рассмотрите возможность сопоставления запроса всем пользователям.
См. Документацию WebSecurity API для получения дополнительной информации.
Вы можете иметь столько защищенных или незащищенных шаблонов URL, сколько захотите.
В Spring Security у вас есть функции аутентификации и контроля доступа для веб-слоя приложения. Вы также можете ограничить доступ пользователей с определенной ролью к определенному URL-адресу и т.д.
Прочитайте ссылку на Spring Security для более подробной информации:
http://docs.spring.io/spring-security/site/docs/current/reference/html/
Приоритет упорядочивания шаблонов URL
При сопоставлении указанных шаблонов с входящим запросом сопоставление выполняется в порядке, в котором элементы объявлены. Таким образом, наиболее конкретные шаблоны соответствий должны стоять первыми, а самые общие - последними.
У метода http.authorizeRequests() есть несколько дочерних элементов, каждый сопоставитель рассматривается в том порядке, в котором они были объявлены.
Шаблоны всегда оцениваются в порядке их определения. Таким образом, важно, чтобы более конкретные шаблоны были определены выше в списке, чем менее конкретные шаблоны.
Читайте здесь для более подробной информации:
http://docs.spring.io/spring-security/site/docs/current/reference/htmlsingle/#filter-security-interceptor
Пример 1
Общее использование метода ignoring()
WebSecurity не включает Spring Security, и ни одна из функций Spring Securitys не будет доступна. WebSecurity базируется выше HttpSecurity
(в конфигурации XML вы можете написать это: <http pattern="/resources/**" security="none"/>
).
@Override
public void configure(WebSecurity web) throws Exception {
web
.ignoring()
.antMatchers("/resources/**")
.antMatchers("/publics/**");
}
@Override
protected void configure(HttpSecurity http) throws Exception {
http
.authorizeRequests()
.antMatchers("/admin/**").hasRole("ADMIN")
.antMatchers("/publics/**").hasRole("USER") // no effect
.anyRequest().authenticated();
}
WebSecurity в приведенном выше примере позволяет Spring игнорировать /resources/**
и /publics/**
. Поэтому .antMatchers("/publics/**").hasRole("USER")
в HttpSecurity не рассматривается.
Это полностью исключит шаблон запроса из цепочки фильтров безопасности. Обратите внимание, что к чему-либо, соответствующему этому пути, не будут применены службы аутентификации или авторизации, и они будут свободно доступны.
Пример 2
Шаблоны всегда оцениваются по порядку. Приведенное ниже сопоставление недопустимо, поскольку первое соответствует каждому запросу и никогда не применяет второе совпадение:
@Override
protected void configure(HttpSecurity http) throws Exception {
http
.authorizeRequests()
.antMatchers("/**").hasRole("USER")
.antMatchers("/admin/**").hasRole("ADMIN"):
}