[Spring] Filter 와 Interceptor 의 차이

 # Spring에서의 Request 데이터 흐름도

Interceptor 의 반환형은 boolean, True 이면 다음단계로 데이터를 전송

Spring request 데이터 흐름도

---

Summary.

필터는 WAS(웹컨테이너)에 의해 관리가 되는 영역이고
인터셉터는 DispatcherServlet(스프링의 프론트컨트롤러) 이후 영역이므로 스프링에 의해 관리되는 영역이다.

공통점은 컨트롤러 진입전 실행로직을 작성할 수 있다는 것.

차이점은 필터는 스프링이 관리하지 않으므로, Spring Context를 사용할 수 없다는 것.

이로 인해 극명히 대조될 때는 에러핸들링을 해야할 때이다.

인터셉터는 @ControllerAdvice 로 스프링의 도움을 받아 객체지향적으로 예외처리를 할 수 있지만,
필터는 직접 response에 접근하여 예외처리를 하거나, 톰캣의 경우 <error-page>를 선언하여 처리하거나, 인터셉터까지 계속 통과시켜 인터셉터에게 예외처리를 미뤄버려야 한다.

만약 인터셉터에게 미루지 않고 에러가 발생한 필터에서 doFilter()를 호출하여 다음필터로 전파하지 않고 바로 return 으로 클라이언트로 response 를 보내게 되면, 프론트 컨트롤러인 디스패처서블릿에 서블릿자체가 도달하지 않으므로 스프링에서는 알 방법이 없다.

시큐리티 필터체인에서 이러한 현상을 한번 목격한 것 같기도 한데, 컨트롤러 앞단에 위치한 인터셉터에서 예외처리를 하고 있는 것일 수도 있어서 (그렇다기엔 그냥 response바디가 빈채로 내려가긴 했었던 것 같다) 이 부분은 시간 날때 한번 검증하고 다시 언급하도록 하겠다.

필터는 디스패처서블릿에 도달하기전에 서블릿을 교체할 수 있다. (여러번 inputStream을 열 수 있도록) 
인터셉터는 템플릿패턴으로 작성된 템플릿메서드들을 사용할 수 있다.

 

Filter 

 - 그림과 같이 데이터 수신의 제일 앞단이자 데이터 송출의 가장 마지막 단

 - 유일하게 ServletRequest, ServeltResponse 객체를 변환 할 수 있는 지점

 - Web Application(톰캣아저씨)에 등록이 된다.

 - 로깅과 인증의 용도로 주로 사용한다.

 - request를 읽어버리면 커서가 제일 끝에 위치하게 되어 오류가 발생한다.

  * chain.doFilter(request, response); 다음에 request를 읽어야 stream 오류가 발생하지 않는다.

  * doFilter 의 매개변수들을 커스터마이징하기도 한다.

 - 마찬가지로 doFilter 이후에 Response 를 읽으면 똑같은 상황이 생기는데, 이는 Response.copyBodyToResponse() 로 해결가능하다.

 - 어느정도 숙련되기전 까지는 로깅용도로만 사용하고, 인증은 Interceptor에게 넘기도록 하자..

---

Interceptor

 - Controller 와 같은 영역에 위치, 따라서 어떠한 컨트롤러와 핸들러가 매핑이 되었는지 알 수 있음

 - Spring Context에 등록 됨 (@Component)

 - 인증 단계를 처리 (컨트롤러의 권한차이를 둠), 인터셉터를 여러개둬서 인증 단계를 여러 개 만들 수도 있다.

 - Interceptor 에서도 request를 읽어버리면 오류가 발생하나, Filter에서 이쁘게만든 request를 넣어주면 Interceptor에서 읽어도 오류가 발생안되게 할 수 있다. (ContentCashingRequestWrapper)

---

Interceptor 등록하기

 

인터셉터 스프링에 등록하기