DelegatingFilterProxy

기존에 알고 있던 스프링 구조

https://mangkyu.tistory.com/221

스프링 콘텍스트 밖에서 필터를 거친 후, 디스패쳐 서블릿(프런트 컨트롤러)이 컨트롤러들에게 요청을 위임하는 방식

 

의문점

우리는 스프링 시큐리티를 사용하면서 스프링 컨텍스트 내부에서 필터를 등록해 사용하는데, 어떻게 스프링 컨텍스트에 도달하기 전에 필터를 거칠 수 있는걸까?

 

DelegatingFilterProxy

현재 필터체인은 크게 2가지가 존재한다.

 

1. 서블릿 컨테이너의 필터체인
2. 스프링 컨테이너의 필터체인

과거에는 필터는 서블릿 컨테이너에만 존재했으며, 필터를 스프링 컨테이너에서 관리할 수 없었다.

그러나, DI와 같은 기술들이 필터에서도 필요해지면서 DelegatingFilterProxy라는 프록시 호출용 필터를 지원하기 시작하였다.

 

흐름 파악

https://gowoonsori.com/blog/spring/architecture/

1. 요청이 서블릿에 있는 필터체인에 도달
2. DelegateFilterProxy에 도달하면, DelegateFilterProxy는 스프링 컨텍스트 내에 있는 필터를 찾아 요청을 위임
3. 스프링 컨텍스트 내부에서 FilterChainProxy(스프링 시큐리티)에 의해 관리되는 필터들을 거침
4. 다시 돌아와서 다음 필터를 수행

 

DelegateFilterProxy의 doFilter 메소드 디버깅

1. 대리 대상 필터 초기화 확인:
   • delegateToUse 변수는 대리 대상 필터를 참조한다.
   • 첫 번째 if문은 delegateToUse가 null인지 확인한다. 즉, 대리 대상 필터가 아직 초기화되지 않았는지 확인한다.
2. 동기화 블록:
   • synchronized 블록은 멀티스레드 환경에서 여러 스레드가 동시에 이 부분을 실행하는 것을 방지한다.
   • 블록 내부에서 다시 한 번 delegateToUse가 null인지 확인한다. 이는 이중 검사 잠금(double-checked locking) 패턴의 일부로, 불필요한 동기화를 방지하기 위해 사용된다.
3. 웹 애플리케이션 컨텍스트 찾기:
   • findWebApplicationContext() 메소드를 호출하여 현재 웹 애플리케이션 컨텍스트를 찾는다.
   • 웹 애플리케이션 컨텍스트가 null이면 IllegalStateException을 발생시킨다. 이는 필터가 올바르게 구성되지 않았음을 나타낸다.
4. 대리 대상 필터 초기화:
   • initDelegate(wac) 메소드를 호출하여, 웹 애플리케이션 컨텍스트에서 대리 대상 필터를 초기화한다.
5. 대리 대상 필터에 작업 위임:
   • invokeDelegate 메소드를 호출하여, 실제 doFilter 작업을 초기화된 대리 대상 필터에 위임한다.

 

서블릿 필터체인에서 DelegatingFilterProxy를 확인 할 수 있다.

 

invokeDelegate -> FilterChainProxy

invokeDelegate 메서드가 실행되면, Spring Security 필터를 관리하는 FilterChainProxy로 이동하게된다. Spring Security는 FilterChainProxy를 통해 내부의 필터들을 관리하며, 내가 직접 등록한 커스텀 필터도 FilterChainProxy에 의해 관리되게 된다.

 

Filterchain → filters 를 확인하면 다음과 같이 필터들이 등록되어있는 것을 볼 수 있다.

세션을 사용하지 않고 커스텀 필터를 등록해서 사용해서 그런지, 강의에서 봤던 15개의 필터와는 조금 다르다.
5, 6번에서 내가 등록한 Jwt 인증 필터와 예외처리 필터를 확인할 수 있다.

 

참조

https://mangkyu.tistory.com/221
https://gowoonsori.com/blog/spring/architecture/

Spring 요청처리 내부구조