[스프링 MVC] 로그인 처리(2) - 필터, 인터셉터

스프링 MVC 2편의 강의 내용을 정리한 포스팅입니다.

---

공통 관심 사항

'로그인 처리(1) - 쿠키, 세션'에서 정의한 요구사항에 따르면 로그인을 한 사용자만 상품 관리 페이지에 들어갈 수 있어야 한다.

하지만 상품 관리 페이지의 URL을 직접 호출하면 로그인을 하지 않은 사용자도 접속할 수 있다는 문제점이 존재한다.

상품 관리 컨트롤러에서 로그인 여부를 체크하는 로직을 일일이 작성할 수도 있지만, 등록/수정/삭제/조회 등 모든 컨트롤러 로직에 공통으로 로그인 여부를 확인해야 하며 로그인과 관련된 로직이 변경될 때마다 작성한 모든 로직을 다 수정해야 하는 가능성이 존재한다.

 

이렇게 애플리케이션 여러 로직에서 공통으로 관심이 있는 부분을 '공통 관심사'라고 하는데, 해당 상황에서의 공통 관심사는 '인증'이다.

이러한 공통 관심사는 스프링의 AOP로도 해결할 수 있지만, 웹과 관련된 공통 관심사는 서블릿 필터 또는 스프링 인터셉터를 사용하는 것이 좋다. 웹 관련 공통 관심사를 처리할 때 대개 HTTP의 헤더나 URL의 정보가 필요한데, 서블릿 필터와 스프링 인터셉터는 HttpServletRequest를 제공하기 때문이다.

 

 

서블릿 필터

필터는 서블릿이 지원하는 수문장으로 아래와 같은 특성을 가진다.

1. 필터 흐름
HTTP 요청 → WAS → 필터 → 서블릿 → 컨트롤러

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

3. 필터 체인
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() {}
}

 

 

서블릿 필터 - 인증 체크

필터를 개발할 때는 Filter 인터페이스를 구현하는 방식으로 진행하면 된다.

 

1. 필터 개발

@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);
                    httpResponse.sendRedirect("/login?redirectURL=" + requestURI); //미인증 사용자 로그인 화면으로 리다이렉트; 로그인 후 기존 접속 페이지 이동 위해 쿼리 파라미터로 경로 전달
                    return; //필터를 더 이상 진행하지 않고 호출 종료
                }
            }

            chain.doFilter(request, response); //다음 필터가 있으면 필터를 호출하고, 없으면 서블릿 호출
        } catch (Exception e) {
            throw e;
        } finally {
            log.info("인증 체크 필터 종료 {}", requestURI);
        }
    }

    //화이트 리스트 여부 구분
    private boolean isLoginCheckPath(String requestURI) {
        return !PatternMatchUtils.simpleMatch(whitelist, requestURI);
    }
}

2. 필터 등록 - FilterRegistrationBean 이용

@Configuration
 public class WebConfig {
    @Bean
    public FilterRegistrationBean logFilter() {
        ...
    }

    @Bean
    public FilterRegistrationBean loginCheckFilter() {
        FilterRegistrationBean<Filter> filterRegistrationBean = new FilterRegistrationBean<>();
        filterRegistrationBean.setFilter(new LoginCheckFilter()); //로그인 필터 등록
        filterRegistrationBean.setOrder(2); //두 번째 순서
        filterRegistrationBean.addUrlPatterns("/*"); //모든 요청에 로그인 필터 적용
        return filterRegistrationBean;
    }
}

 

 

 

스프링 인터셉터

스프링 인터셉터도 서블릿 필터와 같이 웹과 관련된 공통 관심 사항을 해결할 수 있는 기술이다.

차이점이 있다면 서블릿 필터는 서블릿이 제공하는 기술이지만, 스프링 인터셉터는 스프링 MVC가 제공하는 기술이라는 점, 적용되는 순서와 범위 및 사용방법이 다르다는 점이 있다.

1. 스프링 인터셉터 흐름
HTTP 요청 → WAS → 필터 → 서블릿 → 스프링 인터셉터 → 컨트롤러

2. 스프링 인터셉터 제한
로그인 사용자: HTTP 요청 → WAS → 필터 → 서블릿 → 스프링 인터셉터 → 컨트롤러
비 로그인 사용자: HTTP 요청 → WAS → 필터 → 서블릿 → 스프링 인터셉터(적절하지 않은 요청이라 판단, 컨트롤러 호출 X)

3. 스프링 인터셉터 체인
HTTP 요청 → WAS → 필터 → 서블릿 → 인터셉터1 → 인터셉터2 → 인터셉터3 → 컨트롤러

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

정상적인 흐름은 컨트롤러 호출 전 preHandle(), 컨트롤러 호출 후 postHandle(), 요청 이후 afterCompletion()이 호출되는 것이 맞지만 컨트롤러에서 예외가 발생한 경우의 흐름은 다음과 같다.

preHandle()이 컨트롤러 호출 전 호출되고, 컨트롤러에서 예외가 발생하면 postHandle()은 호출되지 않는다. 하지만 afterCompletion()은 예외 발생 여부와 관계없이 항상 호출된다. 예외가 발생한 경우에는 @Nullable Exception ex 파라미터를 통해 예외 종류를 로그로 출력할 수도 있다.

 

서블릿 필터의 경우 단순하게 doFilter() 하나만 제공되지만, 인터셉터는 컨트롤러 호출 전, 후, 요청 완료 이후와 같이 단계적으로 세분화 되어있을 뿐 아니라 ServletRequest, ServletResponse만 제공되는 서블릿 필터와 달리 인터셉터는 어떤 컨트롤러(핸들러)가 호출되는지에 대한 호출 정보와 ModelAndView 정보도 받아볼 수 있어 더욱 정교하고 다양한 기능을 지원한다는 장점이 있다.

 

 

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

1. 인터셉터 개발

인증은 컨트롤러 호출 전에만 검증하면 되므로, preHandle()만 구현하면 된다.

 

@Slf4j
public class LoginCheckInterceptor implements HandlerInterceptor {
    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        String requestURI = request.getRequestURI();

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

        HttpSession session = request.getSession();

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

        return true;
    }
}

2. 인터셉터 등록 - WebMvcConfigurer 이용

@Configuration
public class WebConfig implements WebMvcConfigurer {
    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        registry.addInterceptor(new LogInterceptor()) //인터셉터 등록
                .order(1) //순서 지정
                .addPathPatterns("/**") //인터셉터를 적용할 URL 패턴 지정
                .excludePathPatterns("/css/**", "/*.ico", "/error"); //인터셉터에서 제외할 URL 패턴

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

 

 

ArgumentResolver 활용

스프링 MVC 기본 기능 중 요청 매핑 핸들러 어댑터 구조에서 ArgumentResolver를 다루었는데, 해당 기능을 사용해서도 로그인 회원을 편리하게 찾을 수 있다.

 

1. 컨트롤러 

@GetMapping("/")
public String homeLoginArgumentResolver(@Login Member loginMember, Model model) {
    //세션에 회원 데이터가 없으면 로그인 전 화면으로 이동
    if (loginMember == null) {
        return "home";
    }
    
    //세션이 유지되면 로그인 후 화면으로 이동
    model.addAttribute("member", loginMember);
    return "loginHome";
}

2. @Login 애노테이션 생성

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

}

3. LoginMemberArgumentResolver 생성

public class LoginMemberArgumentResolver implements HandlerMethodArgumentResolver {
    @Override
    public boolean supportsParameter(MethodParameter parameter) {
        ...
    }

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

4. ArgumentResolver 등록 - WebMvcConfigurer 이용

@Configuration
public class WebConfig implements WebMvcConfigurer {
    @Override
    public void addArgumentResolvers(List<HandlerMethodArgumentResolver> resolvers) {
        resolvers.add(new LoginMemberArgumentResolver());
    }
}