WebSecurity.ignoring()을 알아보자

백선장님 인강에서 보면 ignoring 하는 방법과 ignoring 된 요청은

시큐리티 필터 목록 (Filters) 갯수가 "0"임을 확인할 수 있었다.

ignoring() 내부와 어떻게 필터 목록이 0개가 되는지 살펴보고 싶어졌다.

 

 

# ignoring() 

정적인 요청은 시큐리티 설정에서 WebSecurity.ignoring()을 이용하여 필터 적용을 제외할 수 있다.

 

ignoring()외에 다른 방법들도 존재하는데, 어떤 것들이 있는지 살펴보자.

 

 

# 요청 제외 방법

사진에 나와있는 WebSecurity.ignoring()이 제공해주는 제외 방법이 requestMatchers 외에도

다른 방법들이 존재하는데, ignoring 내부를 들어가보면 다음과 같다.

 

IgnoredRequestConfigurer 를 반환해주는데, IgnoredRequestConfigurer의 내부는 다음과 같다.

 

 

부모인 AbstractRequestMatcherRegistry가 제공해주는 방법까지 파악을 해보면

 

1. mvcMatchers : HTTP Method를 파라미터로 넘겨주면 HTTP Method와 요청 URI를 매핑하고,

넘겨주지 않으면 요청 URI는 HTTP Method를 신경쓰지 않는다.

 

스프링 MVC에서 MvcRequestMatcher로 URL을 비교하는 방식을 시큐리티에서도 그대로 적용하여

스프링 MVC가 매핑하는 URL을 보호할 수 있다.

 

문서를 살펴보면 MvcRequestMatcher를 사용하기 위해서는 mvcHandlerMappingIntrospector 라는 이름의 HanderMappingIntrospector 빈이 등록되어 있어야 한다고 한다.

 

이 녀석은 스프링 시큐리티와 스프링 MVC 는 각 컨텍스트에서 초기화가 되므로 각 컨텍스트를 공유할 수 있도록
중간다리를 해주는 역할이라고 한다.

 

그래서 시큐리티에서 MVC 패턴을 사용하여 MVC에서의 URI 매핑 패턴과 시큐리티 패턴을 일치시킬 수 있다.

 

 

2. antMatchers : 제공된 ant 패턴과 일치 할 때만 호출되도록 HttpSecurity를 ​​구성 할 수 있다.

ant 패턴이란 다음과 같다.

? : 1개의 문자와 매칭 (matches single character) * : 0개 이상의 문자와 매칭 (matches zero or more characters) ** : 0개 이상의 디렉토리와 파일 매칭 (matches all files / directories)

 

mvcMatcher와 차이를 예로 들어보면

antMatcher("/account") : /account 라는 URI가 정확하게 일치하는 경우에만 허용 

mvcMatcher("/account") : /account 뿐만 아니라 /account/, /accunt.html, 등을 허용한다.

 

 

3. regexMatchers : 정규 표현식을 이용하여 URI 매칭하는 방식

 

 

4. requestMatchers : FilterChainProxy에 사용되는 RequestMatcher 전략과 수신 요청을 일치시키도록 정의할 수 있는 Matcher를 주입받을 수 있다. (mvcMatcher, antMatcher, regexMatcher가 예이다.)

 

 

위에 설명된 방법으로 요청을 ignoring을 할 수 있게 된다.

즉, SecurityFilterChain에 Filter List에 아무것도 등록이 되지 않는다는 것을 의미한다.

어떻게 필터 목록이 0개가 되는지 시큐리티 설정에 파라미터로 받는 WebSecurity 내부를 살펴보자.

 

 

 

# WebSecurity

javadoc

---

The WebSecurity is created by WebSecurityConfiguration to create the FilterChainProxy known as the Spring Security Filter Chain (springSecurityFilterChain). The springSecurityFilterChain is the Filter that the DelegatingFilterProxy delegates to.

 

Customizations to the WebSecurity can be made by creating a WebSecurityConfigurer, overriding WebSecurityConfigurerAdapter or exposing a WebSecurityCustomizer bean.

 

WebSecurity는 Spring Security Filter Chain(springSecurityFilterChain)으로 알려진 필터 FilterChainProxy을 생성하는 WebSecurityConfiguration에 의해 생성되어진다. springSecurityFilterChain은 DelegatingFilterProxy가 위임하는 필터이다.

 

WebSecurityConfigurer를 만들거나 WebSecurityConfigurerAdapter를 재정의하거나 WebSecurityCustomizer bean을 노출하여 WebSecurity를 커스터마이징을 할 수 있다.

---

즉, WebSecurityConfiguration은 FilterChainProxy을 생성하는데, springSecurityFilterChain 이라는 이름으로 빈을 생성하고, WebSecurityConfiguration에서 WebSecurity의 build()를 수행하면 AbstractSecurityBuilder를 통해 WebSecurity의 performBuild() 메서드가 호출이 된다.

 

performBuild() 수행시, FilterChainProxy를 생성하는 것을 파악할 수 있으며, 

ignoredRequest 같은 경우는 DefaultSecurityFilterChain으로 생성되며 필터 체인에 등록되는 것을 파악할 수 있다.

 

여기서 필터 체인 리스트에 add가 되어지지만 실제로 DefaultSecurityFilterChain 생성자를 보면

등록된 필터는 없기에 DefaultSecurityFilterChain이 생성될 때 마다, Filters는 빈 리스트를 가지게 되어

Filters size가 0이 된다.

 

즉, 

 

List<SecurityFilterChain> securityFilterChains = new ArrayList<>(chainSize);

for (RequestMatcher ignoredRequest : this.ignoredRequests) {
    securityFilterChains.add(new DefaultSecurityFilterChain(ignoredRequest));
}

 

securityFilterChains이 초기화가 된 상태 (필터 목록은 0개이다.)에서

ignoredRequest들은 DefaultSecurityFilterChain으로 생성되어지는데,

DefaultSecurityFilterChain 생성 시 초기화 된 securityFilterChains을 가지고 생성되므로

필터 목록이 0개가 되는 것이다.