시큐리티 아키텍쳐 DelegatingFilterProxy 질문드립니다.

Question

안녕하세요 강사님 좋은 강의 감사드립니다. 위임처리 보면서 궁금한게 있는데 web.xml 이 로드될때 서블릿 컨테이너에 DelegatingFilterProxy 를 등록되고 ApplicationContext에는 springFilterChainBean 이 등록되고 DelegatingFilterProxy 은 springFilterChainBean 를 찾아서 위임처리를 해주는데 이때 각각의 Filter들은 모두 스프링빈이다 라고 요약을 했는데 제대로 했는지 모르겠지만 이부분이 잘 이해가 가지않습니다. 1. 스프링관련 요청은 모두 DispatchServlet를 통한다 생각하고 있었는데 여기서는 springFilterChainBean FIlter를 처리하고 이후에 해 당 request를 DispatchServlet 로 보내는것 같아서 스프링빈의 API를 호출하는것은 DispatchServlet과는 관계가 없다고 생각하면 될까요?(+ http 요청에 대한 부분만 받는건가요?) 2. springFilterChainBean 도 스프링빈인데 Servlet 필터에 스프링빈을 주입만 못하는것이고 스프링빈을 가져다 쓰는것은 문제 없는거라 생각하면 될까요? 저는 지금까지 container는 모두 독립적으로 존재한다? 라고 생각을 하고 있어서 이해가 잘 되지않아 질문 드립니다 감사합니다.

정수원 · Answer

1. 스프링관련 요청은 모두 DispatchServlet를 통한다 생각하고 있었는데 여기서는 springFilterChainBean FIlter를 처리하고 이후에 해 당 request를 DispatchServlet 로 보내는것 같아서 스프링빈의 API를 호출하는것은 DispatchServlet과는 관계가 없다고 생각하면 될까요?(+ http 요청에 대한 부분만 받는건가요?) springFilterChainBean 즉 FilterChainProxy 클래스는 빈으로 생성되고 Filter 인터페이스를 구현하고 있어서 비록 서블릿 컨테이너에서 관리하는 필터가 아니지만 필터의 역할을 함과 동시에 스프링의 기능까지 사용할 수 있도록 한 것이라 볼 수 있습니다. 일석 이조의 효과를 가진다고 볼 수 있습니다. 왜냐하면 FIlter 는 스프링 컨테이너보다 먼저 사용자의 요청을 받는 클래스이기 때문에 보안기능을 구현하기에는 가장 좋은 기술인데 다만 스프링의 기능을 사용하지 못하는 단점이 존재했는데 그 부분을 보완하기 위해 이러한 설계를 도입했다고 보시면 됩니다. 간단하게 생각하자면 FilterChainProxy 는 서블릿에서 관리하는 필터가 아님에도 필터의 역할과 스프링의 기능을 겸비하는 클래스로서 수행을 하는 것이고 그 중계자 역할을 서블릿 컨테이너에서 관리하는 DelegatingFilterProxy 가 하고 있다고 보시면 됩니다. 이것은 DispatchServlet 과는 아무런 상관이 없는 내용입니다 2. springFilterChainBean 도 스프링빈인데 Servlet 필터에 스프링빈을 주입만 못하는것이고 스프링빈을 가져다 쓰는것은 문제 없는거라 생각하면 될까요? 저는 지금까지 container는 모두 독립적으로 존재한다? 라고 생각을 하고 있어서 이해가 잘 되지않아 질문 드립니다 위에서 말씀드린 것처럼 스프링이 기능을 사용함과 동시에 필터의 역할까지 할 수 있는 클래스가 필요했기 때문에 서블릿 컨테이너의 DelegatingFilterProxy 와 스프링 컨테이너의 FilterChainProxy 를 서로 연계하는 방식으로 필터의 역할과 스프링의 기능을 모두 충족한 결과를 가져왔다고 보시면 됩니다.