필터와 인터셉터

Filter 와 Interceptor 가 필요한 이유는 모든 로직에 대하여 인증 절차를 처리하는 Logic 이 있다면, 하나하나 등록을 하는 것 보다 한번에 처리할 수 있는 기능이 있으면 유지보수 하기 쉬워 사용하는 것이다.

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

 

필터 (Filter)

필터를 적용하면 필터가 호출 된 다음에 서블릿이 호출된다.
그래서 모든 고객의 요청 로그를 남기는 요구사항이 존재한다면 필터를 사용하면 된다.

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

 

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

 

필터 체인 (Filter Chain)

 

필터는 체인으로 구성되는데, 중간에 필터를 자유롭게 추가할 수 있다.
예를 들어서 로그를 남기는 필터를 먼저 적용하고, 그 다음에 로그인 여부를 체크하는 필터를 만들 수 있다.

HTTP 요청 -> WAS -> Filter1 -> Filter2 -> Filter3 -> 서블릿 -> 컨트롤러

필터 인터페이스는 다음과 같이 구성되어 있다.

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 destory() {}
}

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

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

사용

@Slf4j
public class LogFIlter implements Filter {

	@Override
	public void init(FilterConfig filterConfig) throws ServletException {
		log.info("log filter Start");
	}

	@Override
	public void doFilter(HttpServletRequest request, HttpServletResponse response, FilterChain chain) throws IOException, ServletException {
		try {
			log.info("doFIlter Start");
			chain.doFilter(request, response); // 가장 중요 (  다음 필터 호출 )
		} catch(Exception e) {
			throw e;
		}
	}

	@Override
	public default void destory() {
		log.info("doFilter Destory");
	}
}

chain.doFilter(request, response) 라는 부분이 제일 중요한데, 다음 필터가 있으면 필터를 호출하고 필터가 없으면 서블릿을 호출한다. 만약 이 로직을 호출하지 않으면 다음 단계로 진행되지가 않는다.

이렇게 나만의 FIlter 를 만들었다면 필터를 설정하여 등록을 해주면 된다.

@Configuration
public class WebConfig {

	@Bean
	public FilterRegistrationBean logFilter() {
		FilterRegistrationBean<Filter> filterRegistrationBean = new FilterRegistrationbean<>();

		filterRegistrationBean.setFilter(new LogFilter());
		filterRegistrationBean.setOrder(1);
		filterRegistrationBean.addUrlPatterns("/*");

		return filterRegistrationBean;
	}
}

필터를 등록하는 방법은 여러가지가 있지만, SpringBoot 를 사용한다면 FilterRegistrationBean 을 사용해서 등록을 해주면 된다.

setFilter(new LogFilter()) : 등록할 필터를 지정한다.
setOrder(1) : 필터는 체인으로 동작을 한다. 따라서 순서가 필요하다.
addUrlPatterns("/*") : 필터를 적용할 URL 패턴을 지정한다. 한번에 여러 패턴을 지정 할 수 있다.

서블릿 필터를 이용한 인증 체크

로그인 되지 않은 사용자는 상품 관리 뿐만 아니라
미래에 개발될 페이지에도 접근하지 못하도록 막는 요건이다.

@Slf4j
public class LoginCheckFilter implements Filter {
	private static final String[] whiteList = {"/", "/members/add", "/login", "/logout", "/css/*"};

	@Override
	public void doFilter(HttpServletRequest request, HttpServletResponse 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("member") == null) {
					log.info("미인증 사용자 요청 {}", requestURI);
					httpResponse.sendRedirect("/login?redirectURL=" + requestURI);
					return; // 미인증 사용자는 다음으로 진행하지 않고 끝
				}
			}
            
			chain.doFilter(request, response);
            
		} catch(Exception e) {
			throw e;
		} finally {
			log.info("인증 체크 필터 종료 {}", requestURI);
		}
	}


	// 화이트 리스트의 경우 인증 체크 X
	private boolean isLoginCheckPath(Strng requestURI) {
		return !PatternMatchUtils.simpleMatch(whilteList, requestURI);
	}
}

httpResponse.sendRedirect("/login?redirectURL=" + requestURI);

미인증 사용자는 로그인 화면으로 리다이렉트 한다. 그런데 로그인 이후에 다시 홈으로 이동해버리면, 원하는 경로를 다시 찾아가야 하는 불편함이 있다. 따라서 현재 요청한 경로인 requestURI 를 /login  에 쿼리 파라미터로 함께 전달한다. 물론 Controller 에서 이를 받아서 후처리를 해야 한다.

 

return

필터를 더는 진행하지 않는다.
이후 필터는 물론 서블릿, 컨트롤러가 더는 호출되지 않는다.
앞서 redirect 를 사용했기 때문에 redirect 가 응답으로 적용되고 요청이 끝나게 된다.

이렇게 등록된 Filter 을 사용할 수 있게 등록을 해주어야 한다.

@Bean
public FilterRegistrationBean loginCheckFilter() {

	@Bean
	public FilterRegistrationBean loginCheckFilter() {
		FilterRegistrationBean<Filter> filterRegistrationBean = new FilterRegistrationBean<>();

		filterRegistrationBean.setFilter(new LoginCheckFilter());
		filterRegistrationBean.getOrder(2);
		filterRegistrationBean.addUrlPatterns("/*");

		return filterRegistrationBean;
	}
}

마지막으로 로그인 인증 Controller  를 개발하면 된다.
즉, 로그인에 성공하면 처음 요청한 URL 로 이동하는 기능이다.

@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("login", loginMember);

	return "redirect:" + redirectURL;
}

서블릿 필터를 잘 사용한 덕분에 로그인 하지 않은 사용자는 나머지 경로에 들어갈 수 없게 되었다.
공통 관심사를 서블릿 필터를 사용해서 해결한 덕분에 향후 로그인 관련 정책이 변경되어도 이 부분만 변경하면 된다.

 

스프링 인터셉터 (Spring Interceptor)

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

스프링 인터셉터의 흐름
HTTP -> WAS -> 필터 -> 서블릿 -> 스프링 인터셉터 -> 컨트롤러

서블릿 인터셉터도 필터처럼 체인 기능을 제공한다.

스프링 인터셉터 체인
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 {}
}

서블릿 필터의 경우 단순하게 doFilter() 하나만 제공디지만, 인터셉터는 컨트롤러 호출 전(preHandle), 컨트롤러 호출 후(PostHandle), 요청 완료 이후(afterCompletion) 아 같이 단계적으로 잘 세분화 되어 있다.

인터셉터에 경우 또한 어떤 컨트롤러(Obejct handler)가 호출되는지 호출 정보를 받을 수 있다.
그리고 어떤 modelAndView 가 반한되는지 응답 정보도 받아 볼 수 있다.

- preHandle : 컨트롤러 호출 전에 호출
- postHandle : 컨트롤러 호출 후에 호출
- afterCompletion : 뷰가 렌더링 된 이후 호출

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

afterCompletion 은 어떤 경우에도 호출되기 때문에, 예외가 발생하면 postHandle 은 호출되지 않으므로 예이와 무관하게 공통 처리를 하고 싶다면 afterCompletion 을 사용하면 된다.

등록

 

서블릿 인터셉터를 등록하기 위해서는 필터처럼 따로 @Configuration 어노테이션을 이용하여 WebMvcConfigurer 인터페이스를 상속받아 등록을 해주면 된다.

@Configuration
public class WebConfig implements WebMvcConfigurer {

	@Override
	public void addInterceptors(InterceptorRegistry registry) {
		registry.addInterceptor(new LogInterceptor())
		.order(1)
		.addPathPatterns("/**")
		.excludePathPatterns("/css/**", "/*.ico", "/error");
	}
}