스프링 인터셉터를 사용해보자

인터셉터란?

필터와 동일하게 공통 관심 사항을 효과적으로 해결할 수 있는 기술이다. 인터셉터는 서블릿이 제공하는 필터와 다르게 스프링 MVC에서 제공하는 기술이며 필터보다 좀 더 편리한 기능을 포함하고 있다. 인터셉터는 스프링 MVC가 제공하기 때문에 디스패쳐 서블릿 이후에 호출되게 된다. 스프링 MVC의 시작점이 디스패처 서블릿이라고 보면 된다. 

 

아키텍처 

 

필터 VS 인터셉터 

큰 틀에는 차이가 없다.

우선 필터와 인터셉터의 전체적인 기능에는 큰 차이가 없다. 필터 인터셉터 둘다 요청에 대한 전후 처리 역할을 수행하여 또한 URL Pattern을 이용하여 어떠한 요청에 대해 역할을 수행할 것인지 지정이 가능하다. 또한 request, response 객체를 받아서 부가적인 로직 또한 개발자가 직접 구현이 가능하다. 

 

자세히 보아야 차이점이 보인다.

전체적인 기능을 보면 같지만 자세히 들여다보면 확실히 차이가 존재한다.  다음은 나만의 옷장 프로젝트에서 구현한 각각 로그 인터셉터와 로그 필터의 메인 구현부이다. 

 

로그 필터 

@Slf4j
public class LogFilter implements Filter {

    @Override
    public void init(FilterConfig filterConfig) throws ServletException {
        log.info("init");
    }

    @Override
    public void destroy() {
        log.info("destroy");
    }

    @Override
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
        log.info("doFilter");

        HttpServletRequest httpRequest = (HttpServletRequest) request;
        String requestURI = httpRequest.getRequestURI();
        String method = httpRequest.getMethod();
        String uuid = UUID.randomUUID().toString();

        try {
            log.info("REQUEST [{}][{}: {}]", uuid, method, requestURI);
            chain.doFilter(request, response); // 다음 필터 호출
        } catch (Exception e) {
            throw e;
        } finally {
            log.info("RESPONSE [{}][{}: {}]", uuid, method, requestURI);
        }
    }
}

 

로그 인터셉터 

@Slf4j
public class LogInterceptor implements HandlerInterceptor {

    public static final String LOG_ID = "logId";

    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        String requestURI = request.getRequestURI();
        String method = request.getMethod();
        String uuid = UUID.randomUUID().toString();

        request.setAttribute(LOG_ID, uuid);

        /**
         * @RequestMapping : HandlerMethod가 넘어옴
         * 정적 리소스 : ResourceHttpRequestHandler
         */
        if (handler instanceof HandlerMethod) {
            HandlerMethod handlerMethod = (HandlerMethod) handler; // 호출할 컨트롤러 메서드의 모든 정보
        }

        log.info("REQUEST [{}][{}: {}], [{}]", uuid, method, requestURI, handler);
        return true;
    }

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

    @Override
    public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) throws Exception {
        String requestURI = request.getRequestURI();
        String method = request.getMethod();
        String uuid = UUID.randomUUID().toString();

        log.info("RESPONSE [{}][{}: {}], [{}]", uuid, method, requestURI, handler);
        if (ex != null) {
            log.error("afterCompletion error!!", ex);
        }
    }
}

 

위의 소스를 비교했을 때 가장 먼저 눈에 띄는 부분은 인터셉터는 총 세 가지의 구현부가 존재하는 것이다. 각각의 구현부에 대해 설명을 해보자면 다음과 같다. 

 

참고) HandlerInterceptor의 override 메서드 

preHandle : 컨트롤러 호출 전에 호출, true면 계속 진행, false면 종료 
postHandle : 컨트롤러 호출 후에 호출 (정확히는 핸들러 어댑터 호출 후에 호출), 만약 컨트롤러에서 예외 발생시 postHandle 은 호출 안됨 
afterCompletion  : 뷰가 렌더링 된 이후에 호출, 예외 발생시 예를 통해 예외를 학인할 수 있음 -> 예외가 발생해도 호출 

doFilter 메서드에서 모든것이 이루어지는 필터와 다르게 인터셉터는 컨트롤러를 실행하기 전(preHandle), 핸들러를 실행한 후(postHandle), 뷰를 렌더링한 후(afterCompletion) 등, Servlet내에서도 메서드에 따라 실행 시점을 다르게 가져간다.

 

다음으로 구현부를 이루고 있는 메서드들의 인자가 다른 것을 볼 수 있다. 인터셉터는 다양한 시점에 따라 나눠져 있는 메서드를 가지고 있기때문에 그 시점에 존재하는 부가적인 변수들을 인자로 가지고 있다. 핸들러를 이용하여 컨트롤러 메서드의 모든 정보를 가져와 좀 더 복합적인 로직을 구현할 수 있고 Exception 변수를 이용하여 예외 로직을 손쉽게 구현할 수 있다. 또한 Spring의 Dispatcher-Servlet 내부에 위치하기 때문에 Exception을 @ControllerAdvice에서 @ExceptionHandler를 이용하여 처리할 수 있다. 

 

다음으로 인터셉터는 필터보다 좀 더 세세한 urlPattern 설정이 가능하다. 

    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        registry.addInterceptor(new LogInterceptor())
                .order(1)
                .addPathPatterns("/api/v1/**")
                .excludePathPatterns("/api/v1/wardrobes");
    }

    @Bean
    public FilterRegistrationBean<Filter> apiAuthorizationFilter() {
        FilterRegistrationBean<Filter> filterRegistrationBean = new FilterRegistrationBean<>();
        filterRegistrationBean.setFilter(new ApiAuthorizationFilter());
        filterRegistrationBean.setOrder(2);
        filterRegistrationBean.addUrlPatterns("/api/v1/*");

        return filterRegistrationBean;
    }

excludePathPattern()과 같이 인터셉터는 좀 더 자세한 urlPatterns를 지정하여 세세한 컨트롤이 가능하다. 

 

마지막으로 필터는 다음 필터에게  request, response 객체를 커스터마이징하여 넘겨줄 수 있다.

public class SomeFilter implements Filter {
  //...
  
  public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) {
    chain.doFilter(new CustomServletRequest(), new CustomResponse());
  }
}

 

 

위와 같이 커스터마이징된 Request, Response 객체를 넘겨주는 경우는 어떤 경우일까?

HttpServletRequest의 바디를 로깅하는 상황을 예로 들 수 있다.  요청 정보를 담은 HttpServletRequest 객체에는 요청 바디를 반환하는 getInputStream() 메서드가 존재한다. 하지만 이 메서드는 최초 1회 호출 후에는 재호출시 java.io.IOException: Stream closed. 예외를 발생시킨다. 일반적인 상황에서는 문제가 없지만 로깅 등의 목적으로 요청 바디를 획득하고자 할 경우 접근이 불가능한 문제가 발생한다. 이 경우 getInputStream()을 재호출이 가능하도록 커스터마이징 된 HttpServletRequest를 제작해야 한다.

 

나만의 옷장 프로젝트에 Request 헤더와 Body를 로깅하는 부분이 있다. 그런데 Body를 로깅하기 위해서는 위에서 언급한 것처럼 커스터마이징된 Response, Request 객체를 넘겨줄 필요가 있었다.

public class CustomServletWrappingFilter extends OncePerRequestFilter {

    @Override
    protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain) throws ServletException, IOException {
        ContentCachingRequestWrapper wrappingRequest = new ContentCachingRequestWrapper(request);
        ContentCachingResponseWrapper wrappingResponse = new ContentCachingResponseWrapper(response);

        filterChain.doFilter(wrappingRequest, wrappingResponse);
        wrappingResponse.copyBodyToResponse();
    }
}

그래서 위와 같이 커스터마이징된 Request와 Response 객체를 넘겨줄 수 있도록 필터를 추가적으로 개발하여 로깅 개발을 완료할 수 있었다. 

 

참고) ContentCachingRequestWrapper, ContentCachingResponseWrapper?

ContentCachingRequestWrapper, ContentCachingResponseWrapper는 inputstream, outputstream의 내용을 캐싱하고, 나중에 다시 가져올 수 있도록 하는 HttpServletResponse의 Wrapper이다.

 

Reference

https://supawer0728.github.io/2018/04/04/spring-filter-interceptor/

(Spring)Filter와 Interceptor의 차이

 

https://jsonobject.tistory.com/522

Spring Boot, HttpServletRequest 객체에서 요청 바디 획득하기