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

 

로그인 여부를 체크하는 로직을  모든 컨트롤러에 공통 적용해야 하는 문제점이 남아있다.(단일 책임 원칙 위배)

이렇게 애플리케이션 여러 로직에서 공통으로 관심이 있는 있는 것을 공통 관심사(cross-cutting concern)라고 한다.

이러한 공통 관심사는 스프링의 AOP로도 해결할 수 있지만,

웹과 관련된 공통 관심사는 지금부터 설명할 서블릿 필터 또는 스프링 인터셉터를 사용하는 것이 좋다

---

 

서블릿 필터

필터는 서블릿이 지원하는 수문장이다. 필터의 특성은 다음과 같다

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

필터를 적용하면 필터가 호출 된 다음에 서블릿이 호출된다.

필터에서 적절하지 않은 요청이라고 판단하면 거기에서 끝을 낼 수도 있다. (서블릿 호출X)

참고로 스프링을 사용하는 경우 여기서 말하는 서블릿은 스프링의 디스패처 서블릿으로 생각하면 된다.

 

필터는 체인으로 구성되는데, 중간에 필터를 자유롭게 추가할 수 있다.

 

필터 구현

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

1. init(): 필터 초기화 메서드, 서블릿 컨테이너가 생성될 때 호출된다.
2. doFilter(): 고객의 요청이 올 때 마다 해당 메서드가 호출된다. 필터의 로직을 구현하면 된다.
3. destroy(): 필터 종료 메서드, 서블릿 컨테이너가 종료될 때 호출된다

 

필터 등록

필터를 등록하는 방법은 여러가지가 있지만, 스프링 부트를 사용한다면 FilterRegistrationBean 을 사용해서 등록하면 된다

 

---

스프링 인터셉터

서블릿 필터가 서블릿이 제공하는 기술이라면, 스프링 인터셉터는 스프링 MVC가 제공하는 기술이다. 둘다 웹과 관련 된 공통 관심 사항을 처리하지만, 적용되는 순서와 범위, 그리고 사용방법이 다르다.

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

 

스프링 인터셉터 흐름

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

 

스프링 인터셉터는 스프링 MVC가 제공하는 기능이기 때문에 결국 디스패처 서블릿 이후, 컨트롤러 호출 직전에 호출된다

인터셉터에서 적절하지 않은 요청이라고 판단하면 컨트롤러 도달 전에 끝을 낼 수도 있다.

 

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

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)와 같이 단계적으로 잘 세분화 되어 있다.

서블릿 필터의 경우 단순히 request, response 만 제공했지만, 인터셉터는 어떤 컨트롤러(handler)가 호출되는지 호출 정보, 어떤 modelAndView 가 반환되는지 응답 정보도 받을 수 있다.

 

 

스프링 인터셉터 호출 흐름

preHandle의 응답값이 true이면 다음으로 진행하고, false이면 더는 진행하지 않는다. false 인 경우 나머지 인터셉터는 물론이고, 핸들러 어댑터도 호출되지 않는다. 그림에서 1번에서 끝이 나버린다.

preHandle 리턴 값이 true 면 정상 호출이다. 다음 인터셉터나 컨트롤러가 호출된다.

스프링 인터셉터 예외 상황

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

 

예외가 발생하면 postHandle()는 호출되지 않으므로 예외와 무관하게 공통 처리를 하려면 afterCompletion()을 사용해야. 

 

 

인터셉터 등록

WebMvcConfigurer 가 제공하는 addInterceptors() 를 사용해서 인터셉터를 등록할 수 있다.

filter와 달리 @Bean으로 등록하는 것이 아니다.

 

---

ArgumentResolver 활용

ArgumentResolver(컨트롤러 호출 직전에 호출 되어서 필요한 파라미터 정보를 생성)를 활용해서

로그인 회원을 간편하게 찾아보자.

before

after

 

1. 애노테이션 생성

 

2. 애노테이션에 로직 적용을 위한 ArgumentResolver  생성

support가 true면 resolveArgument 실행

 

3. ArgumentResolver 등록

 

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

 

---

참고 자료 & 이미지 출처
스프링 MVC 2편 (김영한 님)