해당 글은 인프런의 스프링 MVC 2편 - 백엔드 웹 개발 핵심 기술 인강을 보고 정리한 내용입니다.

로그인 처리 - 필터, 인터셉터

서블릿 필터 - 소개

공통 관심 사항

• 공통 관심사(cross-cutting concern)
  • 애플리케이션에서 여러 로직에 공통적으로 관심이 있는 것
    • 일일이 처리할 경우 중복 코드가 많아지고, 수정 시 모든 공통 로직을 수정해야 하므로 유지보수가 어려워짐
  • 로그인을 해야만 사용할 수 있는 기능 등
    • 예제에서는 등록, 수정, 삭제, 조회 등등 여러 로직에서 공통으로 인증에 대해서 관심을 가지고 있음
  • 스프링 AOP로 해결할 수 있으나 웹과 관련된 공통 관심사는 서블릿 필터 또는 스프링 인터셉터를 사용할 것을 권장
    • 웹과 관련된 다양한 부가 기능 제공
      • 서블릿 필터나 스프링 인터셉터는 HttpServletRequest를 제공

서블릿 필터 소개

필터 흐름

HTTP 요청 -> WAS -> 필터 -> 서블릿 -> 컨트롤러

• 필터를 적용하면 필터가 호출 된 다음에 서블릿이 호출
  • 모든 고객의 요청 로그를 남기는 요구사항이 있다면 필터를 사용
  • 스프링을 사용하는 경우 여기서 말하는 서블릿은 스프링의 DispatcherServlet를 의미

필터 제한

HTTP 요청 -> WAS -> 필터 -> 서블릿 -> 컨트롤러 //로그인 사용자
HTTP 요청 -> WAS -> 필터(적절하지 않은 요청이라 판단, 서블릿 호출X) //비 로그인 사용자

• 필터에서 적절하지 않은 요청이라고 판단하면 로직을 종료시킬 수 있음

필터 체인

HTTP 요청 -> WAS -> 필터1 -> 필터2 -> 필터3 -> 서블릿 -> 컨트롤러

• 필터는 체인으로 구성
  • 중간에 필터를 자유롭게 추가 가능

필터 인터페이스

public interface Filter {
    public default void init(FilterConfig filterConfig) throws ServletException {}
    
    public void doFilter(ServletRequest request, ServletResponse response,
                         FilterChain chain) throws IOException, ServletException;
    
    public default void destroy() {}
}

• 필터 인터페이스를 구현하고 등록하면 서블릿 컨테이너가 필터를 싱글톤 객체로 생성하고, 관리

• init()

  • 필터 초기화 메소드, 서블릿 컨테이너가 생성될 때 호출

• doFilter()

  • 고객의 요청이 올 때 마다 해당 메소드가 호출
  • 필터 로직을 구현하는 메소드

• destroy()

  • 필터 종료 메소드이다.
  • 서블릿 컨테이너가 종료될 때 호출

서블릿 필터 - 요청 로그

LogFilter - 로그 필터

@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 {
        log.info("log filter doFilter");

        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");
    }
}

• public class LogFilter implements Filter {}
  • 필터를 사용하기 위해 필터 인터페이스 구현 필요
• doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
  • HTTP 요청시 doFilter 호출
  • ServletRequest request는 HTTP 요청이 아닌 경우까지 고려해서 만든 인터페이스
    • HTTP 사용하면 HttpServletRequest httpRequest = (HttpServletRequest) request;와 같이 다운 캐스팅을 사용해 진행
• String uuid = UUID.randomUUID().toString();
  • HTTP 요청을 구분하기 위해 요청당 임의의 uuid 생성
• log.info("REQUEST [{}][{}]", uuid, requestURI);
  • uuid, requestURI 출력
• chain.doFilter(request, response);
  • 필터에서 가장 중요한 부분
  • 다음 필터가 있으면 필터를 호출하고, 필터가 없으면 서블릿을 호출
  • 만약 이 로직을 호출하지 않으면 다음 단계로 진행되지 않음

WebConfig - 필터 설정

@Configuration
public class WebConfig {

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

        return filterRegistrationBean;
    }
}

• 스프링 부트를 사용 시 FilterRegistrationBean 사용해서 등록
  • @ServletComponentScan, @WebFilter로도 필터 등록이 가능하지만 필터 순서는 조절할 수 없음
  • setFilter(new LogFilter())
    • 등록할 필터 지정
  • setOrder(1)
    • 체인으로 동작하는 필터의 순서 지정
    • 낮을수록 먼저 동작
• addUrlPatterns("/*")
  • 필터를 적용할 URL 패턴을 지정
  • 한번에 여러 패턴을 지정 가능

실행 로그

NFO 14808 --- [           main] hello.login.web.filter.LogFilter         : log filter init

INFO 15096 --- [nio-8080-exec-1] hello.login.web.filter.LogFilter         : log filter doFilter
INFO 15096 --- [nio-8080-exec-1] hello.login.web.filter.LogFilter         : REQUEST [e31e9be2-91a5-4af5-a43c-bb28a9c2c2cb][/login]
INFO 15096 --- [nio-8080-exec-1] hello.login.web.filter.LogFilter         : RESPONSE [e31e9be2-91a5-4af5-a43c-bb28a9c2c2cb][/login]

• 필터를 등록할 때 urlPattern을 /*로 등록했기 때문에 요청에 모든 해당 필터가 적용

• 요청에 문제가 생길 경우 위와 같이 로그 출력

참고

• UUID를 사용하지 않고 실무에서 HTTP 요청 시 같은 요청의 로그에 모두 같은 식별자를 자동으로 남기는 방법은 logback mdc를 사용

서블릿 필터 - 인증 체크

LoginCheckFilter - 인증 체크 필터

@Slf4j
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/*"};
  • 화이트 리스트를 제외한 나머지 모든 경로에는 인증 체크 로직을 적용
    • 인증 필터를 적용해도 홈, 회원가입, 로그인 화면, css 같은 리소스에는 접근할 수 있어야 하기 때문
    • 화이트 리스트 경로는 인증과 무관하게 항상 허용
• isLoginCheckPath(requestURI)
  • 화이트 리스트를 제외한 모든 경우에 인증 체크 로직을 적용
• httpResponse.sendRedirect("/login?redirectURL=" + requestURI);
  • 미인증 사용자는 로그인 화면으로 리다이렉트
  • 현재 요청한 경로인 requestURI를 /login에 쿼리 파라미터로 함께 전달
  • 이후 /login 컨트롤러에서 로그인 성공 시 해당 경로로 이동하는 기능은 추가로 개발
• return;
  • 필터 이후의 흐름을 진행하지 않기 위해 사용
  • 필터는 물론 서블릿, 컨트롤러가 더는 호출되지 않음
  • redirect를 사용했으므로 redirect가 응답으로 적용되고 요청 종료

WebConfig - loginCheckFilter() 추가

@Bean
public FilterRegistrationBean loginCheckFilter() {
    FilterRegistrationBean<Filter> filterRegistrationBean = new FilterRegistrationBean<>();
    filterRegistrationBean.setFilter(new LoginCheckFilter());
    filterRegistrationBean.setOrder(2);
    filterRegistrationBean.addUrlPatterns("/*");

    return filterRegistrationBean;
}

• setFilter(new LoginCheckFilter())
  • 로그인 필터를 등록한다.
• setOrder(2)
  • 순서를 2번으로 적용
  • 로그 필터 다음에 로그인 필터가 적용
• addUrlpatterns("/*")
  • 모든 요청에 로그인 필터를 적용
  • 수정사항이 생길 경우 필터만 수정하는 방식
  • 로그인 필터가 필요 없는 구간에서도 필터가 적용되는데, 이는 성능에는 큰 영향을 끼치지 않음

RedirectURL 처리

• 로그인에 성공하면 처음 요청한 URL로 이동하는 기능 추가

LoginController - loginV4()

@PostMapping("/login")
public String loginV4(@Valid @ModelAttribute LoginForm form, BindingResult bindingResult,
                      @RequestParam(defaultValue = "/") String redirectURL, HttpServletRequest request) {
    if (bindingResult.hasErrors()) {
        return "login/loginForm";
    }

    Member loginMember = loginService.login(form.getLoginId(), form.getPassword());

    if (loginMember == null) {
        bindingResult.reject("loginFail", "아이디 또는 비밀번호가 맞지 않습니다.");
        return "login/loginForm";
    }

    // 로그인 성공 처리
    // 세션이 있으면 있는 세션 반환, 없으면 신규 세션을 생성
    HttpSession session = request.getSession();

    // 세션에 로그인 회원 정보 보관관
    session.setAttribute(SessionConst.LOGIN_MEMBER, loginMember);


    return "redirect:" + redirectURL;
}

• loginV3()의 @PostMapping("/login") 제거
• 로그인 체크 필터에서 미인증 사용자는 요청 경로를 포함해서 /login에 redirectURL요청 파라미터를 추가해서 요청
  • 이 값을 사용해서 로그인 성공 시 해당 경로로 고객을 redirect

정리

• 서블릿 필터를 통해 로그인 하지 않은 사용자는 나머지 경로에 들어갈 수 없도록 제한
• 공통 관심사를 서블릿 필터를 사용해서 해결
  • 향후 로그인 관련 정책이 변경되어도 필터만 변경

참고

• chain.doFilter(request, response);시 request, response 다른 개겣로 변경 가능
  • ServletRequest, ServletResponse를 구현한 다른 객체를 만들어서 넘기면 해당 객체가 다음 필터 또는 서블릿에서 사용
  • 스프링 인터셉터에서 제공하지 않음

스프링 인터셉터 - 소개

• 서블릿 필터와 같이 웹과 관련된 공통 관심 사항을 효과적으로 해결할 수 있는 기술
  • 서블릿 필터 : 서블릿이 제공하는 기술
  • 스프링 인터셉터 : 스프링 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인 경우 나머지 인터셉터는 물론이고, 핸들러 어댑터도 호출되지 않음
      • 그림 기준으로 1번에서 종료
• postHandle
  • 컨트롤러 호출 후에 호출
    • 더 정확히는 핸들러 어댑터 호출 후에 호출
• afterCompoletion
  • 뷰가 렌더링 된 이후에 호출

스프링 인터셉터 예외 사항

예외 발생 시

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

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

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

정리

• 인터셉터는 스프링 MVC 구조에 특화된 필터 기능을 제공
  • 스프링 MVC를 사용하고, 특별히 필터를 꼭 사용해야 하는 상황이 아니라면 인터셉터를 사용하는 것이 더 편리

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

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 경로와 완전히 별개
  • 더욱 자세하고, 세밀하게 설정 가능
• 자세한 내용은 스프링 API 참조

PathPattern 공식 문서 일부

? 한 문자 일치
* 경로(/) 안에서 0개 이상의 문자 일치
** 경로 끝까지 0개 이상의 경로(/) 일치
{spring} 경로(/)와 일치하고 spring이라는 변수로 캡처
{spring:[a-z]+} matches the regexp [a-z]+ as a path variable named "spring"
{spring:[a-z]+} regexp [a-z]+ 와 일치하고, "spring" 경로 변수로 캡처
{*spring} 경로가 끝날 때 까지 0개 이상의 경로(/)와 일치하고 spring이라는 변수로 캡처
/pages/t?st.html — matches /pages/test.html, /pages/tXst.html but not /pages/
toast.html
/resources/*.png — matches all .png files in the resources directory
/resources/** — matches all files underneath the /resources/ path, including /
resources/image.png and /resources/css/spring.css
/resources/{*path} — matches all files underneath the /resources/ path and
captures their relative path in a variable named "path"; /resources/image.png
will match with "path" → "/image.png", and /resources/css/spring.css will match
with "path" → "/css/spring.css"
/resources/{filename:\\w+}.dat will match /resources/spring.dat and assign the
value "spring" to the filename variable

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

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;
    }
}

• 인증의 경우 컨트롤러 호출 전에만 호출되면 됨
  • 따라서 preHandle만 구현

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

@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 애노테이션을 만들어야 컴파일 오류가 사라짐
  • @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()
  • 컨트롤러 호출 직전에 호출 되어서 필요한 파라미터 정보를 생성
  • 예제에서는 세션에 있는 로그인 회원 정보인 member 객체를 찾아서 반환

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를 활용하면 공통 작업이 필요할 때 컨트롤러를 더욱 편리하게 사용할 수 있음