2015-08-13 5 views
7

В моей Spring загрузки приложения на основе версии 1.3.0.BUILD-SNAPSHOT, у меня есть статические ресурсы (изображения, CSS, JS) в папке static под resources.Правильное использование WebSecurity в WebSecurityConfigurerAdapter

Я вижу некоторые примеры, связанные с конфигурацией безопасности, как следующее:

@Configuration 
@EnableWebSecurity 
public class WebSecurityConfig extends WebSecurityConfigurerAdapter { 

    @Override 
    public void configure(final WebSecurity web) throws Exception { 
     web.ignoring() 
      .antMatchers("/static/**"); 
    } 
} 

Это пример правильно? Каким должен быть эффект? Как проверить, что он работает (например, делать запрос на localhost:8080/something? Что прохладно вещи я могу сделать с WebSecurity?

ответ

14

Ваш пример означает, что Spring (Web) Безопасность игнорирует URL-шаблон, которые соответствуют выражению вы определили ("/static/**"). Этот URL-адрес пропускается Security, поэтому он не защищен.

Позволяет добавлять экземпляры RequestMatcher, которые должны игнорировать Spring Security. Веб-безопасность, предоставляемая Spring Security (включая SecurityContext), не будет доступна в HttpServletRequest, которая соответствует. Обычно регистрируемые запросы должны быть только статическими ресурсами. Для запросов, которые являются динамическими, рассмотрите сопоставление запроса, чтобы разрешить всем пользователям.

См: http://docs.spring.io/autorepo/docs/spring-security/4.0.0.RELEASE/apidocs/org/springframework/security/config/annotation/web/builders/WebSecurity.html

Вы можете иметь столько, сколько URL-шаблон обеспеченными или необеспеченными. С Spring Security у вас есть функции аутентификации и контроля доступа для веб-уровня приложения. Вы также можете restict пользователи, имеющие определенную роль для доступа к partitial Url и так далее ... Посмотрите здесь: http://docs.spring.io/spring-security/site/docs/current/reference/html/

Упорядочение Приоритет шаблона URL

При сопоставлении указанного шаблонов против входящего запроса, сопоставление выполняется в том порядке, в котором объявлены элементы. Таким образом, наиболее характерные шаблоны совпадений должны быть первыми, и самое общее должно быть последним.

Существует несколько дочерних элементов метода http.authorizeRequests() , каждый из которых считается в том порядке, в котором они были объявлены.

Шаблоны всегда оцениваются в том порядке, в котором они определены. Таким образом, важно, чтобы более конкретные шаблоны были определены выше в списке, чем менее конкретные шаблоны.

Посмотрите:

Пример 1
Generell использование WebSecurity ignoring() метод не включает Spring Security и ни одна из особенностей Spring Security будет доступна. WebSecurity основан на HttpSecurity. В Xml-Configuration вы можете написать <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 в приведенном выше примере пусть Спринг игнорируя /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"): 
} 
+0

Кажется разумным. Фактически, защита URL-адреса изображения не имеет большого смысла, если изображение является общедоступным (например, логотип компании в заголовке страницы). – JeanValjean

+0

Да, действительно. Другими примерами являются JavaScript, ресурсы CSS, поэтому весь статический контент, который также может быть кэшируемым. Все URL-адреса, которые вы имеете в виду, должны быть защищены, можно защитить с помощью аутентификации и авторизации. –

+0

Мне интересно: что произойдет, если с тем же приоритетом заказа, 'WebSecurity' говорит' ignore' и 'HttpSecurity' говорит' access ("hasRole ('ROLE_ADMIN')") 'для определенного пути? – JeanValjean

0

Ну в коде вы поделились, если вы были ваши статические файлы, т.е. CSS/JS и т.д. в папке называемые статические тогда все ваши статические ресурсы будут добавлены на страницу, тогда как, если вы не оставили из

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

ни один из ваших статических ресурсов будут загружены.

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

Вот link

+0

Я не уверен. Все изображения, css и js загружаются независимо от этой команды. – JeanValjean

+0

Вы используете весенний ботинок? – PaulRyan17

+0

Конечно. Каждое изображение, css и js находится в 'resources/static' – JeanValjean