스프링 인터셉터(Interceptor)

서블릿 필터와 스프링 인터셉터의 차이점 및 활용

서블릿 필터와 스프링 인터셉터는 둘 다 웹 애플리케이션에서 공통 관심 사항을 처리하는데 사용되지만,

적용되는 순서와 범위, 사용 방법에서 차이가 있습니다.

또한 서블릿 필터가 서블릿이 제공하는 기술이라면, 스프링 인터셉터는 스프링 MVC가 제공하는 기술입니다.

HTTP 요청 흐름

1. HTTP 요청 -> WAS -> 필터 -> 서블릿(디스패처) -> 스프링 인터셉터 -> 핸들러(컨트롤러)

• 필터는 서블릿 단계에서 적용되는 반면, 인터셉터는 스프링 MVC의 기능으로 서블릿 이후에 적용됩니다.
• 필터가 먼저 요청을 가로채고, 적절하지 않다고 판단되면 서블릿을 호출하지 않습니다.
• 인터셉터는 컨트롤러가 실행되기 전에 요청을 가로채며, 이후 단계를 진행할지 결정합니다. 인터셉터에서 적절하지 않은 요청이라고 판단하면 거기에서 끝을 내고 컨트롤러를 호출하지 않습니다.
• 스프링 인터셉터도 필터처럼 체인으로 구성되는데, 중간에 인터셉터를 자유롭게 추가할 수 있습니다.

스프링 인터셉터의 구성

스프링 인터셉터를 사용하려면 HandlerInterceptor 인터페이스를 구현해야 합니다.

이 인터페이스는 세 가지 메서드를 제공합니다:

HandlerInterceptor를 먼저 보겠습니다.

public interface HandlerInterceptor {

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

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

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

}

메서드 설명

1. preHandle(): 컨트롤러 호출 전에 실행되며(더 정확히는 핸들러 어댑터 호출 전에 호출), 요청이 허용될지 여부를 결정합니다. 반환 값이 true이면 요청이 컨트롤러로(다음 인터셉터로) 넘어가고, false이면 요청 처리가 중단됩니다.
2. postHandle(): 컨트롤러가 호출된 후(더 정확히는 핸들러 어댑터 호출 후에 호출 ), 뷰가 렌더링되기 전에 실행됩니다.
3. afterCompletion(): 요청 처리가 완료된 후(뷰 렌더링 이후) 실행됩니다. 예외가 발생해도 호출됩니다.

서블릿 필터의 경우 단순하게 doFilter() 하나만 제공되었는데

인터셉터는 컨트롤러 호출 전(preHandle), 호출 후(postHandle), 요청 완료 이후(afterCompletion)와 같이

단계적으로 잘 세분화 되어 있습니다.

또한 서블릿 필터의 경우 단순히 request , response 만 제공했지만

인터셉터는 어떤 컨트롤러(handler)가 호출되는지 호출 정보도 받을 수 있습니다.

그리고 어떤 modelAndView가 반환되는지 응답 정보도 받을 수 있습니다.

afterCompletion에서는 에러 정보도 받을 수 있습니다.

 

** 컨트롤러에서 예외가 발생하면 postHandle 은 호출되지 않습니다. 하지만 afterCompletion 은 항상 호출되므로 이 경우 예외(ex)를 파라미터로 받아서 어떤 예외가 발생했는지 로그로 출력할 수 있습니다.

** afterCompletion은 예외가 발생해도 호출됩니다. 예외가 발생하면 postHandle() 는 호출되지 않으므로 예외와 무관하게 공통 처리를 하려면 afterCompletion() 을 사용해야 합니다. 예외가 발생하면 afterCompletion()에 예외 정보(ex)를 포함해서 호출됩니다.

 

이제 인터셉터를 구현해봅시다.

스프링 인터셉터 구현 예시

1. LoginCheckInterceptor: 로그인 체크 로직을 수행하는 인터셉터

@Slf4j
public class LoginCheckInterceptor implements HandlerInterceptor{
	
	@Override
	public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {

		String requestURI = request.getRequestURI();

		log.info("인증 체크 인터셉터 실행 {}", requestURI);

		HttpSession session = request.getSession();
		if (session == null || session.getAttribute(SessionConst.LOGIN_MEMBER) == null) {
			log.info("미인증 사용자 요청");
			// 로그인으로 redirect
			response.sendRedirect("/login?redirectURL=" + requestURI);
			return false;
		}

		return true;
	}
}

HandlerInterceptor를 implements한 Class를 만들어줍니다. 위 코드는 별게 없습니다.

preHandle에서 로그인 여부를 확인하고, 미인증 사용자는 로그인 페이지로 리다이렉트합니다.

HandlerInterceptor만 implements한 후에 preHandle에서 session 확인하는게 전부입니다.

다른 예시도 보겠습니다.

 2. LogInterceptor: 요청 및 응답 로그를 남기는 인터셉터

@Slf4j
public class LogInterceptor implements HandlerInterceptor{
	
	private 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;
	}

	@Override
	public void postHandle(HttpServletRequest request, HttpServletResponse response, Object handler, @Nullable ModelAndView modelAndView) throws Exception {
		log.info("postHandle [{}]", modelAndView);
	}
	
	@Override
	public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, @Nullable Exception ex) throws Exception {
		
		String requestURI = request.getRequestURI();
		String logId = (String)request.getAttribute(LOG_ID);

		log.info("RESPONSE [{}][{}][{}]", logId, requestURI, handler);

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

preHandle에서 logId를 생성해 요청에 저장하고, 이 값을 afterCompletion에서 사용하여 종료 로그를 기록합니다.

 

위의 예시에서 눈여겨 보아야할 점은 preHandle에서 request.setAttribute(LOG_ID, uuid) 이 부분입니다.

uuid로 생성한 logId 값을 다른 곳에서도(afterCompletion) 쓰기 위함인데요.

서블릿 필터의 경우 지역변수로 해결이 가능하지만, 스프링 인터셉터는 호출 시점이 완전히 분리되어 있습니다.

따라서 preHandle 에서 지정한 값을 postHandle , afterCompletion 에서 함께 사용하려면 어딘가에 담아두어야 합니다. LogInterceptor도 싱글톤처럼 사용되기 때문에 멤버변수를 사용하면 위험합니다.

따라서 request에 담아서 request.getAttribute(LOG_ID) 로 찾아서 사용합니다.

 

**HandlerMethod

핸들러 정보는 어떤 핸들러 매핑을 사용하는가에 따라 달라집니다.

스프링을 사용하면 일반적으로 @Controller , @RequestMapping 을 활용한 핸들러 매핑을 사용하는데,

이 경우 핸들러 정보로 HandlerMethod가 넘어옵니다.

ResourceHttpRequestHandler @Controller가 아니라 /resources/static 와 같은 정적 리소스가 호출 되는 경우에 ResourceHttpRequestHandler가 핸들러 정보로 넘어오기 때문에 타입에 따라서 처리가 필요합니다.

 

**postHandle, afterCompletion

종료 로그를 postHandle이 아니라 afterCompletion에서 실행한 이유는

예외가 발생한 경우 postHandle가 호출되지 않기 때문입니다.

afterCompletion은 예외가 발생해도 호출되는 것을 보장합니다.

 

이제 인터셉터 사용을 위해서 WebConfig에 등록을 해봅시다.

인터셉터 등록

인터셉터를 사용하려면 설정 파일(@Configuration)에서 이를 등록해줘야 합니다.

WebMvcConfigurer를 구현한 설정 클래스(WebConfig)에서 addInterceptors 메서드를 통해 등록할 수 있습니다.

@Configuration
public class WebConfig implements WebMvcConfigurer {

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

		registry.addInterceptor(new LoginCheckInterceptor())
				.order(2)
				.addPathPatterns("/**")
				.excludePathPatterns("/", "/members/add", "/login", "/logout", "/css/**", "/*.ico", "/error");
	}
}

 

• registry를 이용하여 설정
• addInterceptor(new LogInterceptor()): 인터셉터를 등록
• order(1): 로그 인터셉터를 1순위로 적용
• addPathPatterns("/**"): 인터셉터를 적용할 URL 패턴을 지정. 여기선 모든 경로에 대해 인터셉터를 적용
• excludePathPatterns("/css/**", "/*.ico", "/error"): 인터셉터에서 제외할 패턴을 지정 . 특정 경로는 인터셉터에서 제외

 

필터와 비교해보면 인터셉터는 addPathPatterns , excludePathPatterns로 매우 정밀하게 URL 패턴을 지정 할 수 있습니다.

필터와 인터셉터의 차이점

• 적용 위치: 필터는 서블릿 레벨, 인터셉터는 스프링 MVC 레벨에서 동작
• 사용 범위: 필터는 웹 애플리케이션 전반에서 사용되지만, 인터셉터는 스프링 MVC와 관련된 요청에만 적용
• 메서드 구성: 필터는 doFilter() 하나의 메서드를 사용하지만(물론 init과 destroy도 있긴 하지만 여기서는 실제 로직), 인터셉터는 preHandle(), postHandle(), afterCompletion()으로 세분화되어 있음
• URL 패턴 관리: 인터셉터는 addPathPatterns, excludePathPatterns를 통해 매우 정밀한 URL 패턴 관리를 지원

인터셉터는 보다 스프링 MVC에 특화된 요청 처리를 가능하게 하며,

필터와 달리 핸들러(컨트롤러)와 관련된 정보를 다룰 수 있습니다.

 

출처 : 인프런, 김영한-스프링MVC 2편