스프링 MVC 2편 - 백엔드 웹 개발 활용 기술을 공부하고 정리하는 포스트입니다.

스프링 인터셉터

  • 서블릿 필터와 같이 웹 관련 공통 관심 사항을 효과적으로 해결할 수 있는 기술
    • 서블릿 필터 : 서블릿이 제공하는 기술
    • 스프링 인터셉터 : 스프링 MVC가 제공하는 기술
    • 둘 다 웹과 관련된 공통 관심 사항을 처리하지만, 적용되는 범위, 사용 방법의 차이가 있음

스프링 인터셉터 흐름

HTTP 요청 → WAS → 필터 → 서블릿 → 스프링 인터셉터 → 컨트롤러
  • DispatcherServlet과 컨트롤러 사이에서 컨트롤러 호출 직전에 호출
  • 스프링 MVC가 제공하는 기능이기 때문에 결국 DispatcherServlet 이후에 등장
    • 스프링 MVC의 시작점이 DispatcherServlet이라고 볼 수 있음
  • URL 패턴 적용 가능
    • 서블릿 URL 패턴과 달리 매우 정밀하게 설정 가능

스프링 인터셉터 제한

HTTP 요청 → WAS → 필터 → 서블릿 → 스프링 인터셉터 → 컨트롤러 //로그인 사용자
HTTP 요청 → WAS → 필터 → 서블릿 → 스프링 인터셉터(적절하지 않은 요청이라 판단 → 컨트롤러 호출 X) // 비 로그인 사용자
  • 인터셉터에서 적절하지 않은 요청이라 판단 → 그 시점에서 요청 종료 가능

스프링 인터셉터 체인

HTTP 요청 → WAS → 필터 → 서블릿 → 인터셉터1 → 인터셉터2 → 컨트롤러
  • 체인으로 구성 → 중간에 자유롭게 추가 가능
  • 서블릿 필터와 호출되는 순서가 다르며 서블릿 필터보다 편리하고 더 정교하고 다양한 기능을 지원

스프링 인터셉터 인터페이스

  • 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 {}
}
  • 서블릿 필터는 doFilter() 하나만 제공
  • 인터셉터는 단계적으로 세분화되어 있음
    • preHandle : 컨트롤러 호출 전
    • postHandle : 컨트롤러 호출 후
    • afterCompletion : 요청 완료 이후
  • 서블릿 필터 → 단순하게 request, response만 제공
  • 인터셉터 → 어떤 컨트롤러(handler)가 호출되는지 확인 가능
    • 어떤 ModelAndView가 반환되는지 응답 정보도 확인 가능

스프링 인터셉터 호출 흐름


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

스프링 인터셉터 예외 상항


  • preHandle
    • 컨트롤러 호출 전에 호출
  • postHandle
    • 컨트롤러에서 예외가 발생하면 postHandle은 호출되지 않음
  • afterCompletion
    • afterCompletion은 항상 호출
    • 예외 발생 시 예외(ex)를 파라미터로 받을 수 있음

afterCompletion은 예외가 발생해도 호출된다.

  • 예외가 발생하면 postHandle()은 호출되지 않음
    → 예외와 무관하게 공통 처리를 하려면 afterCompletion()을 사용
  • 예외가 발생하면 afterCompletion()에 예외 정보를 포함해서 호출

스프링 인터셉터 - 요청 로그

LogInterceptor 요청 로그 인터셉터

@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 handlerMethod = (HandlerMethod) handler; // 호출할 컨트롤러 메소드의 모든 정보가 포함되어 있다.
        }

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

    @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 uuid = (String) request.getAttribute(LOG_ID);

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

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

}
  • String uuid = UUID.randomUUID().toString()
    • 요청 로그를 구분하기 위한 uuid 생성
  • request.setAttribute(LOG_ID, uuid)
    • 서블릿 필터의 경우 지역변수로 해결이 가능하지만, 스프링 인터셉터는 호출 시점이 완전히 분리되어 있음
      → 따라서 preHandle에서 지정한 값을 postHandle, afterCompletion에서 함께 사용하려면 어딘가에 값을 저장해야 함
    • 싱글톤 처럼 사용되므로 멤버변수를 사용하는 것은 위험
      → 따라서 위 예제에서는 request에 저장
  • return true
    • true면 정상 호출
    • 다음 인터셉터나 컨트롤러가 호출
// @RequestMapping : HandlerMethod
// 정적 리소스 : ResourceHttpRequestHandler
if (handler instanceof HandlerMethod) {
    HandlerMethod handlerMethod = (HandlerMethod) handler; // 호출할 컨트롤러 메소드의 모든 정보가 포함되어 있다.
}
  • HandlerMethod
    • 핸들러 정보는 어떤 핸들러 매핑을 사용하는가에 따라 달라짐
    • 스프링을 사용하면 일반적으로 @Controller, @RequestMapping을 활용한 핸들러 매핑을 사용하는데, 이 경우 핸들러 정보로 HandlerMethod가 전달
  • ResourceHttpRequestHandler
    • @Controller가 아니라 /resources/static와 같은 정적 리소스가 호출 되는 경우 ResourceHttpRequestHandler가 핸들러 정보로 전달
    • 타입에 따라 처리 필요
  • postHandler, afterCompletion
    • 종료 로그를 postHandler가 아니라 afterCompletion에서 실행한 이유는 예외가 발생한 경우 postHandler가 호출되지 않기 때문
    • afterCompletion은 예외가 발생해도 호출 되는 것을 보장

WebConfig 인터셉터 등록

@Configuration
public class WebConfig implements WebMvcConfigurer {

    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        registry.addInterceptor(new LogInterceptor())
                .order(1)
                .addPathPatterns("/**")
                .excludePathPatterns("/css/**", "/*.ico", "/error");
    }
    
    // ...
}
  • WebMvcConfigurer가 제공하는 addInterceptors()를 사용해서 인터셉터 등록
  • registry.addInterceptor(new LogInterceptor())
    • 인터셉터 등록
  • order(1)
    • 인터셉터의 호출 순서 지정
    • 낮을 수록 먼저 호출
  • addPathPatterns("/**")
    • 인터셉터를 적용할 URL 패턴 지정
  • excludePathPatterns("/css/**", "/*.ico", "/error")
    • 인터셉터에서 제외할 패턴 지정
    • addPathPatterns, excludePathPatterns로 매우 정밀하게 URL 패턴을 지정 가능

스프링의 URL 경로

  • 스프링이 제공하는 URL 경로는 서블릿 기술이 제공하는 URL 경로와 완전히 별개
    • 더욱 자세하고, 세밀하게 설정 가능

스프링 인터셉터 - 인증 체크

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(false);

        if (session == null || session.getAttribute(SessionConst.LOGIN_MEMBER) == null) {
            log.info("미인증 사용자 요청");

            // 로그인으로 redirect
            response.sendRedirect("/login?redirectURL=" + requestURI);
            return false;
        }

        return true;
    }
}
  • 인증의 경우 컨트롤러 호출 전에만 호출되면 됨 → 따라서 preHandler만 구현

순서주의, 세밀한 설정 가능

@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");
    }
}
  • 인터셉터를 적용하거나 하지 않을 부분은 addPathPatterns와 excludePathPatterns에 작성
    • 기본적으로 모든 경로에 해당 인터셉터를 적용(/**)
      → 홈(/), 회원 가입(/members/add), 로그인(/login), 리소스 조회(/css/**), 오류(/error)와 같은 부분은 로그인 체크 인터셉터를 적용하지 않음

ArgumentResolver 활용

  • ArgumentResolver를 활용하여 세션에서 로그인 회원을 조금 더 편리하게 조회

HomeController 추가

@GetMapping("/")
public String homeLoginV3SpringArgumentResolver(@Login Member loginMember, Model model) {

    // 세션에 회원 데이터가 없으면 home
    if (loginMember == null) {
        return "home";
    }

    // 세션이 유지되면 로그인으로 이동
    model.addAttribute("member", loginMember);
    return "loginHome";
}
  • @Login 애노테이션이 있으면 직접 만든 ArgumentResolver가 동작해서 자동으로 세션에 있는 로그인 회원을 찾아주고, 만약 세션에 없다면 null을 반환

@Login 애노테이션 생성

@Target(ElementType.PARAMETER)
@Retention(RetentionPolicy.RUNTIME)
public @interface Login {

}
  • @Target(ElementType.PARAMETER) : 파라미터에만 사용
  • @Retention(RetentionPolicy.RUNTIME) : 리플렉션 등을 활용할 수 있도록 런타임까지 애노테이션 정보가 남이있음

LoginMemberArgumentResolver 생성

  • HandlerMethodArgumentResolver의 구현체
@Slf4j
public class LoginMemberArgumentResolver implements HandlerMethodArgumentResolver {

    @Override
    public boolean supportsParameter(MethodParameter parameter) {
        log.info("supportsParameter 실행");

        boolean hasLoginAnnotation = parameter.hasParameterAnnotation(Login.class);
        boolean hasMemberType = Member.class.isAssignableFrom(parameter.getParameterType());

        return hasLoginAnnotation && hasMemberType;
    }

    @Override
    public Object resolveArgument(MethodParameter parameter, ModelAndViewContainer mavContainer, NativeWebRequest webRequest, WebDataBinderFactory binderFactory) throws Exception {

        log.info("resolveArgument 실행");

        HttpServletRequest request = (HttpServletRequest) webRequest.getNativeRequest();
        HttpSession session = request.getSession(false);
        if (session == null) {
            return null;
        }

        return session.getAttribute(SessionConst.LOGIN_MEMBER);
    }

}
  • supportsParameter()
    • @Login 애노테이션이 있으면서 Member 타입이면 해당 ArgumentResolver가 사용
  • resolveArgument()
    • 컨트롤러 호출 직전에 호출 되어서 필요한 파라미터 정보를 생성

WebMvcConfigurer에 설정 추가

@Configuration
public class WebConfig implements WebMvcConfigurer {

    @Override
    public void addArgumentResolvers(List<HandlerMethodArgumentResolver> resolvers) {
        resolvers.add(new LoginMemberArgumentResolver());
    }

    @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");
    }
}
  • LoginMemberArgumentResolver를 오버라이딩한 addArgumentResolvers 내부에 등록

결과는 동일하지만 더 편리하게 로그인 회원 정보를 조회할 수 있다.

  • ArgumentResolver를 활용하면 공통 작업이 필요할 때 컨트롤러를 더욱 편리하게 사용할 수 있음