김영한의 스프링 MVC 2편 - 필터, 인터셉터

Question

• 서블릿 필터, 인터셉터가 AOP보다 나은 점은?
• AOP가 서블릿 필터, 인터셉터보다 나은 점은?
• 필터, 인터셉터, AOP의 실행 순서는?
• 스프링 인터셉터의 호출 흐름은?
• 스프링 인터셉터에서 예외가 발생해도 호출되는 함수와 호출되지 않는 함수는?
• 스프링 인터셉터가 필터보다 부가적으로 제공해주는 기능은?

 

서블릿 필터, 인터셉터, AOP

• 여러 로직에 공통으로 관심이 있는 것을 공통 관심사라고 함
• 이러한 공통 관심사를 처리할 수 있는게 서블릿 필터, 인터셉터, AOP
• 웹과 관련된 공통 관심사를 처리할 때는 서블릿 필터, 인터셉터가 AOP보다 좋음
• 그 이유는, HttpServletRequest를 제공해주므로 HTTP의 헤더, URL 정보 등에 대한 접근이 훨씬 용이함
• 반면에 AOP는 메서드 호출, 예외 발생, 어노테이션 기반 등의 관심사에 대한 접근이 가능해 로깅, 트랜잭션 관리, 보안 검사 등에 활용됨

 

요청 플로우

HTTP 요청 -> WAS(톰캣) -> 필터 -> 서블릿 -> 인터셉터 -> AOP -> 컨트롤러

• WAS(Web Application Server)
  • 클라이언트의 HTTP 요청을 가장 먼저 받습니다.
  • 톰캣, 제티, 언더토우와 같은 WAS는 요청을 적절한 웹 애플리케이션으로 전달합니다.
• 필터(Filter)
  • WAS는 요청을 필터 체인(Filter Chain)을 통해 처리합니다.
  • 여러 필터들이 체인 형태로 연결되어 있으며, 각 필터는 요청 전후에 특정 작업을 수행할 수 있습니다.
  • 필터는 보안 검사, 로깅, 인코딩 설정 등의 목적으로 사용됩니다.
•  서블릿(Servlet)
  • 디스패처 서블릿(DispatcherServlet)은 스프링 MVC의 진입점으로, 핸들러 매핑을 통해 적절한 컨트롤러를 찾습니다.
  • 요청을 적절한 컨트롤러 메서드로 매핑합니다.
• 인터셉터(Interceptor)
  • 인터셉터도 체인 형태로 연결 됩니다.
  • 핸들러 실행 전(preHandle), 핸들러 실행 후(postHandle), 완료 후(afterCompletion) 단계에서 작동할 수 있습니다.
• AOP(Aspect Oriented Programming)
  • AOP는 메서드 호출 전후, 예외 발생 시 등 특정 조건과 지점에서 동작하는 횡단 관심사를 처리합니다.
  • 인터셉터와 서블릿 사이에 동작하며, 보통 실제 컨트롤러 메서드가 호출되기 전, 후에 추가적인 로직을 수행합니다.

 

서블릿 필터

@Slf4j
public class LogFilter implements Filter {
    
    @Override
    public void init(FilterConfig filterConfig) throws ServletException {
        log.info("log filter init");
    }

    @Override
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
            throws IOException, ServletException {
        
        HttpServletRequest httpRequest = (HttpServletRequest) request;
        String requestURI = httpRequest.getRequestURI();
        String uuid = UUID.randomUUID().toString();

        try {
            log.info("REQUEST [{}][{}]", uuid, requestURI);
            chain.doFilter(request, response);
        } catch (Exception e) {
            throw e;
        } finally {
            log.info("RESPONSE [{}][{}]", uuid, requestURI);
        }
    }

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

• 필터 인터페이스를 구현하고 등록하면 서블릿 컨테이너가 필터를 싱글톤 객체로 생성, 관리
• init(): 필터 초기화 메서드, 서블릿 컨테이너가 생성될 때 호출
• doFilter(): 고객의 요청이 올 때 마다 해당 메서드가 호출
• destroy(): 필터 종료 메서드, 서블릿 컨테이너가 종료될 때 호출
• doFilter의 ServletRequest는 HTTP 요청이 아닌 경우도 고려된 부분이라 HTTP 요청에 대해 사용하려면 (HttpServletRequest) request 와 같이 다운캐스팅 하여 사용
• doFilter에서 chain.doFilter가 매우 중요하며, 이 부분이 없으면 다음 단계로 진행이 되지 않음
• 필터에는 인터셉터엔 없는 기능 중에 하나가 chain.doFilter(request, response); 를 호출해서 다음 필터 또는 서블릿을 호출할 때 request , response 를 다른 객체로 바꿀 수 있음
• 잘 사용하는 기능은 아니지만 필터에만 있는 기능

 

서블릿 필터 설정

@Configuration
public class WebConfig {

    @Bean
    public FilterRegistrationBean<Filter> logFilter() {
        FilterRegistrationBean<Filter> filterRegistrationBean = new FilterRegistrationBean<>();
        filterRegistrationBean.setFilter(new LogFilter());
        filterRegistrationBean.setOrder(1);
        filterRegistrationBean.addUrlPatterns("/*");
        return filterRegistrationBean;
    }
}

• setFilter로 등록할 필터 지정
• setOrder로 필터 체인을 등록하며, 숫자가 낮을수록 먼저 동작
• addUrlPatterns 로 적용할 URL 패턴을 지정하며 위는 모든 케이스에 동작하도록 지정
• 위 Configuration 말고 필터 구현체에 @ServletComponentScan @WebFilter(filterName = "logFilter", urlPatterns = "/ *") 이런식으로 필터 등록이 가능하지만 이는 필터 순서 조절이 불가능함
  
  

 

서블릿 필터 예시 - 인증 체크 

@Slf4j
@WebFilter("/*")
public class LoginCheckFilter implements Filter {

    private static final String[] whitelist = {"/", "/members/add", "/login", "/logout", "/css/*"};

    @Override
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
            throws IOException, ServletException {

        HttpServletRequest httpRequest = (HttpServletRequest) request;
        String requestURI = httpRequest.getRequestURI();
        HttpServletResponse httpResponse = (HttpServletResponse) response;

        try {
            log.info("인증 체크 필터 시작 {}", requestURI);
            
            if (isLoginCheckPath(requestURI)) {
                log.info("인증 체크 로직 실행 {}", requestURI);
                HttpSession session = httpRequest.getSession(false);

                if (session == null || session.getAttribute(SessionConst.LOGIN_MEMBER) == null) {
                    log.info("미인증 사용자 요청 {}", requestURI);
                    
                    // 로그인으로 redirect
                    httpResponse.sendRedirect("/login?redirectURL=" + requestURI);
                    return; // 여기가 중요, 미인증 사용자는 다음으로 진행하지 않고 끝!
                }
            }
            
            chain.doFilter(request, response);
        } catch (Exception e) {
            throw e; // 예외 로깅 가능하지만, 톰캣까지 예외를 보내주어야 함
        } finally {
            log.info("인증 체크 필터 종료 {}", requestURI);
        }
    }

    /**
     * 화이트 리스트의 경우 인증 체크X
     */
    private boolean isLoginCheckPath(String requestURI) {
        return !PatternMatchUtils.simpleMatch(whitelist, requestURI);
    }
}

• 모든 요청에 대해 필터로 들어오게 하고 whitelist = {"/", "/members/add", "/login", "/logout","/css/*"} 화이트 리스트는 인증과 상관없이 패스 가능하도록 지정
• return을 해버리면 미인증 사용자는 다음으로 진행하지 못함

 

 

스프링 인터셉터

• 디스패처 서블릿과 컨트롤러 사이에서 호출됨
• 스프링 MVC가 제공하는 기능이므로 디스패처 서블릿 이후인데, 스프링 MVC의 시작점이 디스패처 서블릿
• 서블릿과 비교하면 URL과 패턴이 다르고 매우 정밀하게 설정 가능

 

스프링 인터셉터 호출 흐름

• preHandle : 컨트롤러 호출 전에 호출(더 정확히는 핸들러 어댑터 호출 전에 호출)
  • preHandle 의 응답값이 true 이면 다음으로 진행하고, false 이면 더는 진행하지 않음
  • false 인 경우 나머지 인터셉터는 물론이고, 핸들러 어댑터도 호출되지 않음.
  • 그림에서 1번에서 끝이 나버림
• postHandle : 컨트롤러 호출 후에 호출 (더 정확히는 핸들러 어댑터 호출 후에 호출)
• afterCompletion : 뷰가 렌더링 된 이후에 호출

 

스프링 인터셉터 예외 흐름

• preHandle : 컨트롤러 호출 전에 호출
• postHandle : 컨트롤러에서 예외가 발생하면 postHandle 은 호출되지 않음
• afterCompletion : afterCompletion 은 항상 호출
  • 이 경우 예외( ex )를 파라미터로 받아서 어떤 예 외가 발생했는지 로그로 출력 가능
  • 예외와 무관하게 공통 처리를 하려면 afterCompletion에서 해야함

 

스프링 인터셉터 예제 - 로깅

@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 uuid = UUID.randomUUID().toString();

        request.setAttribute(LOG_ID, uuid);
        
        // @RequestMapping: HandlerMethod
        // 정적 리소스: ResourceHttpRequestHandler
        if (handler instanceof HandlerMethod) {
            HandlerMethod hm = (HandlerMethod) handler; // 호출할 컨트롤러 메서드의 모든 정보가 포함되어 있다.
        }
        log.info("REQUEST [{}][{}][{}]", uuid, requestURI, handler);

        return true; // false일 경우 진행되지 않음
    }

    @Override
    public void postHandle(HttpServletRequest request, HttpServletResponse response, Object handler, 
            ModelAndView modelAndView) throws Exception {
        log.info("postHandle [{}]", modelAndView);
    }

    @Override
    public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, 
            Exception ex) throws Exception {

        String requestURI = request.getRequestURI();
        String logId = (String) request.getAttribute(LOG_ID);
        log.info("RESPONSE [{}][{}]", logId, requestURI);

        if (ex != null) {
            log.error("afterCompletion error!!", ex);
        }
    }
}

• return true 면 정상 호출되고 다음 인터셉터나 컨트롤러가 호출 됨
• 에외 발생시는 postHandle이 아니라 afterCompletion에서 처리

 

 

스프링 인터셉터 등록

@Configuration
public class WebConfig implements WebMvcConfigurer {

    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        registry.addInterceptor(new LogInterceptor())
                .order(1)
                .addPathPatterns("/**")
                .excludePathPatterns("/css/**", "/*.ico", "/error");
    }

    //...
}

• 모든 패턴 등록이 필터와 다르게 /** 임
• 필터와 비교해서 excludePathPatterns로 URL 패턴을 더욱 정밀하게 조절 가능
• 일반적으로 이러한 기능들이 필터에 비해 인터셉터에 더 많아 왠만하면 인터셉터를 사용