스프링은 서블릿 컨테이너의 생명주기와 스프링 ApplicationContext의 생명주기간 연결점을 만드는 것이 주요 역할인 DelegatingFilterProxy 를 제공한다. 이를통해 서블릿 컨테이너는 스프링 출신의 필 를 본인의 필터 체인에 껴줄 수 있음. 하지만 DelegatingFilterProxy 는 빈이 아니기 때문에, 스프링과 연관된 일을 하려면 이들을 모두 Filter 라는 스프링 빈에게 위임한다.
그래서 이름이
Delegating이다.
여기서 더 나아가서 Bean Filter하나가 아니라, 이걸 또 체인으로 만들면 다음처럼 서블릿 필터에 스프링 필터체인이 끼어들 수 있다. 이 역할은 FilterChainProxy 가 수행한다. 이 친구는 특별한 형태의 Filter 구현체로, 많은 Filter 구현체들이 SecurityFilterChain 이라는 필터 체인내에서 수행될 수 있도록 함. FilterChainProxy 는 빈으로 등록되기 때문에 DelegatingFilterProxy 가 로직을 위임할 수 있다.
💡 즉,
FilterChainProxy부터 스프링컨테이너의 영역이 시작된다.
여기서 SecurityFilterChain 을 더 자세히 그린 그림은 다음과 같다.
SecurityFilterChain 이 친구는 FilterChainProxy 내에서 어떤 시큐리티 필터가 사용될지 선택되면, 체인을 시작하는 역할을 한다.
DelegatingFilterProxy 를 빈으로 등록안하고, 진입점을 FilterChainProxy 로 둔건 여러 이점이 있다고 한다. 먼저 모든 스프링 시큐리티의 서블릿에 관한 진입점이 정해져있으므로, 관련문제를 여기서 부터 디버깅하면 된다.
또한 FilterChainProxy가 언제 호출되는지도 유연하게 결정할 수 있다고 함. 서블릿 필터들은 모두 URL기반으로 호출되지만, FilterChainProxy 는 RequestMatcher 인터페이스를 통해 모든 HTTPRequest를 대상으로 호출될 수 있다고 한다.
아마
DelegatingFilterProxy는 어쨌든 기존 서블릿 필터 체인 내에 껴있으므로, 기존 서블릿 필터 체인의 흐름을 거스르기는 어렵기 때문에 진입점을 따로 만든 것 같다.
다음 그림을 보면, 여러 SecurityFilterChain이 등록될 수 있음도 알 수 있다.