애플리케이션 여러 로직에서 공통으로 관심이 있는 것을 공통 관심사(cross-cutting concern)라고 한다. 이러한 공통 관심사는 스프링의 AOP로도 해결할 수 있지만, 웹과 관련된 공통 관심사는 서블릿 필터나 스프링 인터셉터를 사용하는 것이 좋다. 웹과 관련된 공통 관심사를 처리할 때는 HTTP의 헤더나 URL의 정보가 필요한데, 서블릿 필터나 스프링 인터셉터는 HttpServletRequest를 제공한다.
Servlet Filter
필터는 서블릿이 지원하는 수문장이다.
필터 흐름
HTTP 요청 -> WAS -> 필터 -> 서블릿 -> 컨트롤러
스프링을 사용하는 경우 여기서 말하는 서블릿은 스프링의 dispatcher servlet으로 생각하면 된다.
필터 제한
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(): 고객의 요청이 들어올 때마다 해당 메서드가 호출된다. 필터의 로직을 구현하면 된다.
- destroty(): 필터 종료 메서드. 서블릿 컨테이너가 종료될 때 호출된다.
필터 사용
...
public void doFilter(ServletRequest request, ServletResponse response,
FilterChain chain) throws IOException, ServletException {
...
chain.doFilter(request, response);
...
}
...- ServletRequest는 HttpServletRequest의 부모 인터페이스이다. 기능이 별로 없기 때문에 down casting이 필요하다. -> (HttpServletRequest) request
- chain.doFilter를 해줘야 다음 필터를 호출해주거나, 없으면 서블릿을 호출한다.(해주지 않으면 해당 필터에서 흐름이 끝난다.)
@Configuration
public class WebConfig {
@Bean
public FilterRegistrationBean logFilter() {
FilterRegistrationBean<Filter> filterRegistrationBean = new FilterRegistrationBean<>();
filterRegistrationBean.setFilter(new LogFilter()); // 필터 등록.
filterRegistrationBean.setOrder(1); // 필터의 순서를 등록. 숫자가 낮을수록 먼저 동작.
filterRegistrationBean.addUrlPatterns("/*"); // 적용할 url 패턴을 등록. 한 번에 여러 패턴 지정 가능.
return filterRegistrationBean;
}
}- 필터를 사용하려면 필터를 등록해야 된다. 스프링 부트를 사용한다면 FilterRegistrationBean을 사용해서 등록하면 된다.
Spring Interceptor
서블릿 필터가 서블릿이 제공하는 기술이라면, 스프링 인터셉터는 스프링 MVC가 제공하는 기술이다.
스프링 인터셉터 흐름
HTTP 요청 -> WAS -> 필터 -> 서블릿 -> 스프링 인터셉터 -> 컨트롤러
스프링 인터셉터 제한
HTTP 요청 -> WAS -> 필터 -> 서블릿 -> 스프링 인터셉터 -> 컨트롤러 // 로그인 사용자
HTTP 요청 -> WAS -> 필터 -> 서블릿 -> 스프링 인터셉터(적절하지 않은 요청이라 판단, 컨트롤러 호출X) // 비 로그인 사용자
스프링 인터셉터 체인
HTTP 요청 -> WAS -> 필터 -> 서블릿 -> 인터셉터1 -> 인터셉터2 -> 컨트롤러
스프링 인터셉터 인터페이스
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(): 컨트롤러 호출 전에 호출된다.(더 정확히는 핸들러 어댑터 호출 전에 호출된다.) prehandle의 응답값이 true이면 다음으로 진행하고, false이면 더는 진행하지 않는다. false인 경우 나머지 인터셉터는 물론이고, 핸들러 어댑터도 호출되지 않는다.
- postHandle(): 컨트롤러 호출 후에 호출된다.(더 정확히는 핸들러 어댑터 호출 후에 호출된다.)
- afterCopletion(): 뷰가 렌더링 된 이후에 호출된다.
인터셉터는 어떤 컨트롤러(handler)가 호출되는지 호출 정보도 받을 수 있다. 그리고 어떤 modelAndView가 반환되는지 응답 정보도 받을 수 있다.
스프링 인터셉터 예외
예외가 발생시
- preHandle(): 컨트롤러 호출 전에 호출된다.
- postHandle(): 컨트롤러에서 예외가 발생하면 postHandle은 호출되지 않는다.
- afterCompletion(): afterCompletion은 항상 호출된다. 이 경우 예외(ex)를 파라미터로 받아서 어떤 예외가 발생했는 지 로그로 출력할 수 있다.
만약 에러 발생 여부와 무관하게 확인하고 싶은 값이 존재한다면 preHandle에서 request.getAttribute()를 활용한다면 afterCompletion에서 쓸 수 있다.(request와 response의 동일성이 보장된다는 것을 꼭 기억하자.)
인터셉터 등록
@Configuration
public class WebConfig implements WebMvcConfigurer {
@Override
public void addInterceptors(InterceptorRegistry registry) {
registry.addInterceptor(new LogInterceptor())
.order(1)
.addPathPatterns("/**")
.excludePathPatterns("/css/**", "/*.ico", "/error");
}
//...
}- 스프링이 제공하는 url 경로는 서블릿 기술이 제공하는 url 경로와 완전히 다르다. 더욱 자세하고, 세밀하게 설정할 수 있다.
