서론
토이 프로젝트로 로그인을 인터셉터로 구현하던 중이었다. 그런데 팀원 중 한 분이 시큐리티는 필터를 사용하는데 무엇을 써야할지에 대한 의문을 내셨다. 나는 인터셉터가 제공하는 기능들이 편리하기 때문에 사용했는데 조금 더 알아보기로 했다.
차이점
- Filter와 Interceptor는 실행 시점이 다르다.
- Filter는 스프링 밖에 Web Application에 존재하고, Interceptor는 스프링에 존재한다.
- Filter는 스프링에 오기 전에 처리할 수 있기 때문에 스프링까지 들어오는 필요를 줄여준다.
- Interceptor는 스프링이 기능을 제공하기 때문에 편리하다.
대략 이런 내용들이 많다.
@ExceptionHandler
솔직히 경험이 부족해서인지 위의 차이점들이 크게 공감이 가지 않는다.
하지만 진행하다 보니 @ExceptionHandler를 사용하게 되면서 더 중요한 차이점을 알게 되었다.
실행 시점이 달라서 발생하는 가장 큰 차이는 **@ExceptionHandler을 사용할 수 있느냐 없느냐의 차이**라고 생각한다.
Interceptor는 스프링이 관리하기 때문에 컨트롤러만 존재한다면, 인터셉터에서 throw만 해줘도
@ExceptionHandler가 핸들링이 가능하다. 하지만, Filter는 스프링 영역이 아니기 때문에
직접 `request.getRequestDispatcher("/api/error").forward(request, response)와 같이 직접 다루어야 한다. 당연히 /api/error` 컨트럴로도 만들어야 하는 번거로움이 발생한다.
처리 시점
Filter와 Interceptor는 실행 시점이 다르기 때문에
- Filter는 servlet에서 처리하기 전후를 다룰 수 있다.(와닿지 않는 부분이다.)
- Interceptor는 Handler 실행 전(preHandler), 실행 후(postHandler), view 렌더링 후(aftercompletion)과 같이
메서드로 실행 시점을 구분하고 있다.
Filter에서만 할 수 있는 것
ServeltRequest, ServletResponse를 교체할 수 있다는 것이다.
public class SomeFilter implements Filter {
//...
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) {
chain.doFilter(new CustomServletRequest(), new CustomResponse());
}
}와닿지 않는 부분이다.
마무리
Filter와 Interceptor에 대해 모든 것을 이해하지는 못했다. 하지만 현재 나의 상황에 맞는 것은 Interceptor라고 생각한다.
API 응답을 위해 @ExceptionHandler를 사용해야하기 때문에 훨씬 더 코드적으로 효율적이라고 생각했다.
Filter를 사용했을 때 현재 나에게 이득을 주는 부분을 찾지 못하기도 했다.
물론 로그인 인증 시 컨트롤러가 없는 요청이기 때문에, Filter와 같이 `request.getRequestDispatcher()를 해주어야 하는 상황도 있다. 하지만, 인가 시에는 @ExceptionHandler를 사용할 수 있기 때문에 인증과 인가를 통일하여 가져가는 것이 관리 측면에서도 좋을 것 같아 Interceptor`로 처리하기로 했다.
출처
