Spring Security 구조에 대해서 - DelegatingFilterProxy

2023.11.24 - [웹/Spring] - Spring Security 구조에 대해서 - 필터에 대해서

Spring Security 구조에 대해서 - 필터에 대해서

이전글을 이어서 작성하도록 하겠습니다. 

참조 원서:

https://docs.spring.io/spring-security/reference/servlet/architecture.html#servlet-filterchainproxy

Architecture :: Spring Security

DelegatingFilterProxy란?

스프링은 서블릿 컨테이너의 lifecycle와 스프링의 ApplicationContext 간의 연결을 가능하게 하는 DelegatingFilterProxy라는 필터 구현체를 제공합니다.

서블릿 컨테이너는 자체 표준을 사용하여 filter 인스턴스를 등록할 수 있지만, 스프링에서 정의된 빈(Bean)에 대해서는 인지하지 못합니다.

서블릿 컨테이너 원리을 통해 DelegatingFilterProxy를 등록할 수 있지만, 모든 작업을 filter를 구현한 스프링 bean에 위임합니다.

 

해석하면 위와같은데 내용이 참 어렵죠. 그래서 좀더 자세히 설명하기전에 간단히 개념부터 보겠습니다.

여기서  ApplicationContext 란?

https://velog.io/@choidongkuen/Spring-Application-Context-%EB%9E%80

[Spring] Application Context 란?

간단히 말해서 스프링의 컨테이너인데

토비스프링 3.1에서  page 95 쯤에   ApplicationContext은 bean factory랑 비슷하다고 생각하라고 합니다. 동일시한다 라고 써잇더라고요.

원래는 토비스프링 3.1에서도 말하지만 bean factory보다는 좀더 확장된 개념이 ApplicationContext이다라고 합니다

아무튼 어떤 기능에 대한 확장이니까 bean 객체들을 관리하는 IOC엔진이라고 생각하면 편합니다.

 

여기서 초보자 분들은 

IOC는 역전 제어가 뭐지?라고 할수있습니다. 간단히 설명하면 IOC는 spring framework에  의존하는 방식이라 생각하면 좀 편합니다. 뭐 간단히 객체 생성같은거를 개발자가 아니라 framework가 대신해주는거죠! (말그대로 자동화!, 사람의 실수를 줄이는 거죠! 항상 개발자는 사람은 실수한다는 마음으로 개발해야 자동화를 하려고 노력하는것 같아요!)

.

이번엔 서블릿 컨테이너는 이전링크에서말했던 서블릿을 관리하는 컨테이너 겠죠

정의는 서블릿 컨테이너(Servlet Container)는 자바 웹 애플리케이션에서 중요한 역할을 하는 구성 요소입니다. 자바 서블릿을 실행하는 환경을 제공하며, 웹 서버와 함께 동작하여 HTTP 요청과 응답을 처리하는 역할입니다.

 

아래는 filter chain과 filter 인스턴스안에 DelegatingFilterProxy의 모습입니다.

 

 

 

DelegatingFilterProxy는 Bean Filter0 가 호출될때 ApplicationContext의 Bean Filter0에서 나타납니다. 아래 간단히 코드를 확인해보죠

 

public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) {
	Filter delegate = getFilterBean(someBeanName); //1
	delegate.doFilter(request, response);  //2
}

여기서 1 번코드를 보면요

Filter delegate = getFilterBean(someBeanName); //1

여기서 스피링 빈에 등록된 필터는 lazily 하게 가져옵니다.(spring에서 lazy는 직접적 호출하기전까지는 생성및 초기화를 하지 않는다! 라고는걸로 있습니다. 즉 lazy 에 대한 개념을 알고가면 좋습니다.)

예를들어 DelegatingFilterProxy에서의 delegate 는 bean filter0의 instacne입니다.

 

여기서 delegate란?

일반적으로 객체가 특정 작업을 다른 객체에 위임하는 개념입니다. 즉 여기서 말하고자 하는것은 bean filter0가  DelegatingFilterProxy다 라고 생각하면 좋을듯합니다 ( 제가 틀렷다면 지적부탁드리겠습니다 제가 이해한건 이거입니다 )

 

여기서 2번 코드를 보면요

delegate.doFilter(request, response);  //2

Spring bean에서 delgate 작업을 한다라고 합니다. 즉  DelegatingFilterProxy가 작동합니다

 

원문을 해석하면 

마지막으로  DelegatingFilterProxy의 또 다른 장점은 Filter bean 인스턴스를 찾는 것을 지연시킬 수 있다는 것입니다. 이는 컨테이너가 시작되기 전에 Filter 인스턴스를 등록해야 하기 때문에 중요합니다. 그러나 Spring에서는 일반적으로 ContextLoaderListener를 사용하여 Spring Beans를 로드하는데, 이는 Filter 인스턴스가 등록되어야 할 시점 이후에야 완료됩니다.

 

말이 참 어렵죠.

먼저 ContextLoaderListener란?

주로 웹 기반의 Spring 애플리케이션에서 중요한 역할을 하며, 애플리케이션의 시작과 종료 시점에 각각 컨텍스트를 초기화하고 정리하는 역할을 합니다.( 즉 ApllicaitonContext를 초기화 및 종료 하는 역할 이라고 생각하면 편합니다.  일단 이것도 제가 생각한거라 틀릴수 잇습니다. 틀리면 지적부탁드립니다)

 

그렇다면 

쉽게 설명하자면  spring에서 spring filter 인스턴스가 등록되어야 할 시점 이후에 ApplicationContext에서 spring beans을 불러오는겁니다. 근데 어째서 DelegatingFilterProxy는 필터 인스턴스를 늦게 로드 시킬까요?

(이유는 성능 최적화에 있다고하는데  . 당연한 얘기겟지만 모든 컴포너트를 즉시 로딩하면 상당한 양의 메모리를 차지하기 때문에 이런방식을 택한것같습니다. 이건 제추측입니다. 이것도 틀리면 지적부탁드립니다 보통 lazy한 경우가 다 성능 최적화여서 ㅠㅠ )

다음엔 securityFilterChain에 대해서 정리해보겠습니다.