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