Filter vs Interceptor

🟥 Filter

Filter란 Dispatcher Servlet에 요청이 전달되기 전/후에 url 패턴에 맞는 모든 요청에 대한 부가작업을 처리할 수 있는 기능을 제공한다.

Dispatcher Servlet은 스프링의 가장 앞단에 존재하는 Front Controller이므로 필터는 스프링 범위 밖에서 처리가 되는 것이다. 

즉, 필터는 스프링 컨테이너가 아닌 톰캣과 같은 웹 컨테이너에 의해 관리된다. 

 

Filter 메소드 

1️⃣ init 메소드

필터 객체를 초기화하고 서비스에 추가하기 위한 메소드이다. 

웹 컨테이너가 1회 init 메소드를 호출하여 필터 객체를 초기화하면 이후의 요청들은 doFilter를 통해 처리된다. 

public default void init(FilterConfig filterConfig) throws ServletException {}

 

2️⃣ doFilter 메소드

url-pattern에 맞는 모든 HTTP 요청이 Dispatcher Servlet으로 전달되기 전에 웹 컨테이너에 의해 실행되는 메소드이다.

doFilter의 파라미터로는 FilterChain이 있는데 FilterChain의 doFilter를 통해 다음 대상으로 요청을 전달하게 된다. 

chain.doFilter() 전/후에 필요한 처리과정을 넣어줌으로써 원하는 처리를 진행할 수 있다. 

public void doFilter(ServletRequest request, ServletResponse response,
            FilterChain chain) throws IOException, ServletException;

 

3️⃣destroy 메소드 

필터 객체를 서비스에서 제거하고 사용하는 자원을 반환하기 위한 메소드이다. 

웹 컨테이너에 의해 1번 호출되며 이후에는 이제 doFilter에 의해 처리되지 않는다. 

public default void destroy(){}

---

🟧 Interceptor

Interceptor는 Filter와 달리 Spring이 제공하는 기술이다. 

Dispatcher Servlet이 컨트롤러를 호출하기 전과 후에 요청과 응답을 참조하거나 가공할 수 있는 기능을 제공한다. 

즉, 웹 컨테이너(서블릿 컨테이너)에서 동작하는 필터와 달리 인터셉터는 Spring Context에서 동작을 하는 것이다. 

 

Dispatcher Servlet은 핸들러 매핑을 통해 적절한 컨트롤러를 찾도록 요청하는데 그 결과로 실행 체인(HandlerExecutionChain)을 돌려준다. 그래서 이 실행체인에 1개 이상의 인터셉터가 등록되어 있다면 순차적으로 인터셉터들을 거쳐 컨트롤러가 실행되도록 하고 인터셉터가 없다면 바로 컨트롤러를 실행한다. 

 

즉, 간단히 말해서 

필터를 다 거치고 http request가 Dispatcher Servlet에 보내져서 url에 매핑된 Controller에게 보내고 db를 연결해서 모델에 데이터를 담아 뷰에 던지는 작업은 Spring Context에서 일어난다. 

 

Interceptor 메소드 

1️⃣ preHandle 메소드

Controller가 호출되기 전에 실행된다.

Controller 이전에 처리해야 하는 전처리 작업이나 요청 정보를 가공 또는 추가하는 데 사용할 수 있다.

반환 타입은 boolean으로 true면 다음 단계로 진행되지만 false라면 작업을 중단하여 이후의 작업은 진행되지 않는다.

default boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler)
        throws Exception {
        
        return true;
}

 

2️⃣ doFilter 메소드

Controller가 호출된 후에 실행된다. 

이후 처리해야 하는 후처리 작업이 있을 때 사용할 수 있다. 

파라미터에 ModelAndView가 있는데 최근에는 Json 형태의 RestController를 만들면서 자주 사용되지 않는다. 

default void postHandle(HttpServletRequest request, HttpServletResponse response, Object handler,
        @Nullable ModelAndView modelAndView) throws Exception {
}

 

3️⃣afterCompletion 메소드 

모든 View에서 최종 결과를 생성하는 일을 포함해 모든 작업이 완료된 후에 실행된다. 

default void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler,
        @Nullable Exception ex) throws Exception {
}

---

 

❓Filter와 Interceptor는 둘 다 AOP인데 왜 둘로 나눠놨을까?

각각의 책임과 동작 범위가 다르기 때문에 나뉘어 있으며, 서로를 대체할 수는 없고 보완적으로 사용된다. 

 

• Filter는 서블릿 스펙의 일부로, Java EE(Web 표준) 기술이다.
• Interceptor는 Spring MVC 프레임워크 내부의 기능
• AOP는 메서드 단위의 관심사 분리를 위해 사용한다. (@Around, @Transactional 등)

 

Filter는 Spring Context의 밖에 존재한다.

그래서 예를 들어 http request를 보낸 client가 해커가 아닌지, XSS 공격하는지, CORS 정책을 잘 따르면서 보냈는지 먼저 filter를 통해 거르고 통과한 요청만 spring context에 보낸다던가,

유저가 로그인해서 인증 토큰으로 jwt 토큰을 받았는데, 이게 위조된게 아닌지 필터에서 먼저 확인한 후 보낸다. 

• CORS 정책 검사
• JWT 토큰 유효성 검사 (인증 : 이 요청이 Spring에 들어올 자격이 있는가?)
• XSS 방어
• HTTP Method 강제 우회 방지 

✅ Filter가 Spring Bean으로 등록이 안돼서 그랬다? 는 말의 진실

부분적으로 맞다. 과거에는 Filter는 Servlet Container에서 관리되므로 Spring의 DI(의존성 주입) 기능을 직접 사용할 수 없었다. 
그래서 HandlerInterceptor가 만들어졌다. 
그러나 최근에는 @Component로 등록한 Filter를 @Bean으로 등록하거나 FilterRegistrationBean으로 설정하면 Spring Bean 처럼 다룰 수 있다. 
하지만, 여전히 Filter는 DispatcherServlet보다 먼저 실행되므로, AOP나 Spring의 다양한 기능과 완전하게 통합된게 아니다. 

 

 

Interceptor는 Spring Context 안에 존재한다. 

• 인증/인가 처리, 로그인 여부 확인, 권한 체크 (인가: Spring Controller를 실행해도 괜찮은 사용자인가?)
• 로깅/감사 추적: 사용자의 요청 URI 등을 로그에 남기기, API 호출 시간 측

즉, 필터는 스프링과 무관하게 전역적으로 처리해야 하는 작업들을 처리할 수 있다. 

인터셉터에서는 클라이언트의 요청과 관련되어 전역적으로 처리해야 하는 작업들을 처리할 수 있다. 

 

---

---

참고: https://okky.kr/questions/1346808

https://mangkyu.tistory.com/173