8. Filter & Interceptor
필터(Filter)
: 디스패처 서블릿에 요청이 전달되기 전 / 후 url 패턴에 맞는 모든 요청에 대해 부가 작업을 처리할 수 있는 기능을 제공
cf) 디스패처 서블릿
: 스프링의 가장 앞단에 존재하는 프론트 컨트롤러
- 필터는 스프링 범위 밖에서 처리가 됨
- 톰캣과 같은 웹 컨테이너에 의해 관리가 됨
- 디스패처 서블릿 전 / 후에 처리됨
- 스프링 빈으로 등록 가능
필터의 메소드
1. Inint
: 필터 객체를 초기화하고 서비스에 추가하기 위한 메소드
- 웹 컨테이너가 1회 init 메소드를 호출하여 필터 객체를 초기화하면 이후의 요청들은 doFilter를 통해 처리됨
2. doFilter
: url-pattern에 맞는 모든 HTTP 요청이 디스패처 서블릿으로 전달되기 전에 웹 컨테이너에 의해 실행되는 메서드
- doFilter의 파라미터로 FilterChain이 있는데, FilterChain의 doFilter를 통해 다음 대상으로 요청을 전달하게 됨
- chain.doFilter() 전 / 후에 필요한 처리 과정을 넣어줌으로써 원하는 처리를 진행할 수 있음
3. destroy
: 필터 객체를 서비스에서 제거하고 사용하는 자원을 반환하기 위한 메소드
- 웹 컨테이너에 의해 한 번 호출되며, 이후 doFilter에 의해 처리되지 않음
인터셉터(Interceptor)
: 디스패처 서블릿이 컨트롤러를 호출하기 전과 후에 요청과 응답을 참조하거나 가공할 수 있는 기능을 제공
- Spring이 제공하는 기술
- 스프링 컨텍스트에서 동작을 함
- 디스패처 서블릿은 핸들러 매핑을 통해 적절한 컨트롤러를 찾도록 요청함
-> 그 결과로 실행체인을 돌려줌
- 실행체인은 1개 이상의 인터셉터가 등록되어 있다면 순차적으로 인터셉터들을 거쳐 컨트롤러가 실행되고, 없다면 바로 컨트롤러를 실행함
인터셉터의 메소드
1. preHandle 메소드
: 컨트롤러가 실행되기 전에 실행
- 컨트롤러 이전에 처리해야 하는 전처리 작업이나 요청 정보를 가공하고나 추가하는 경우에 사용할 수 있음
- 3번 째 파라미터인 handler 파라미터는 핸들러 매핑이 찾아준 컨트롤러 빈에 매핑되는 HandlerMethod라는 새로운 타입의 객체로써, @RequestMapping이 붙은 메소드의 정보를 추상화한 객체
- preHandler의 반환 타입은 boolean인데 반환값이 true이면 다음 단계로 진행되지만 false라면 작업을 중단하여 이후의 작업은 진행되지 않음
- 이후의 작업은 다음 인터셉터 또는 컨트롤러
2. postHandler
: 컨트롤러를 호출한 후에 실행됨
- 컨트롤러 이후에 처리해야 하는 후처리 작업이 있을 때 사용할 수 있음
- 컨트롤러가 반환하는 ModelAndView 타입의 정보가 제공되는데, 최근에는 Json 형태로 데이터를 제공하는 RestAPI 기반의 컨트롤러(@RestController)를 만들면서 자주 사용되지는 않음
- 컨트롤러 하위 계층에서 작업 중 예외가 발생하면 postHandler는 호출되지 않음
3. afterCompletion
: 모든 뷰에서 최종 결과를 생성하는 일을 포함해 모든 작업이 완료된 후에 실행됨
- 요청 처리 중에 사용한 리소스를 반환할 때 사용하기에 적합
- postHandler와 달리 컨트롤러 하위 계층에서 작업을 진행하다가 중간에 예외가 발생하더라도 afterCompletion은 반드시 호출됨
필터 vs 인터셉터
대상 | 필터 | 인터셉터 |
관리되는 컨테이너 | 서블릿 컨테이너 | 스프링 컨테니어 |
스프링의 예외 처리 | X | O |
Request / Response 객체 조작 가능 여부 | O | X |
용도 | 1. 공통된 보안 및 인증 / 인가 관련 작업 2. 모든 요청에 대한 로깅 또는 감사 3. 이미지 / 데이터 압축 및 문자열 코딩 4. Spring과 분리되어야 하는 기능 |
1. 세부적인 보안 및 인증 / 인가 공통 작업 2. API 호출에 대한 로깅 또는 감사 3. Controller로 넘겨주는 정보 가공 |