[SpringBoot] interceptor, filter, AOP 차이

자바 웹 개발을 하다보면, 공통적으로 처리해야 할 업무들이 많다.예를들어 로그인 관련(세션체크)처리, 권한체크, XSS(Cross site script)방어, pc와 모바일웹의 분기처리, 로그, 페이지 인코딩 변환 등이 있다. 공통업무에 관련된 코드를 모든 페이지 마다 작성 해야한다면 중복된 코드가 많아지게 되고 프로젝트 단위가 커질수록 서버에 부하를 줄 수도있으며, 소스 관리도 되지 않는다.

즉, 공통 부분은 빼서 따로 관리하는게 좋다. 이러한 공통업무를 메서드 호출 전, 중간, 뒤에 추가하여 자동으로 처리할 수 있는 방법이 3가지가 있다.

• Filter
• Interceptor
• AOP

Filter, Interceptor, AOP 의 흐름

Interceptor와 Filter는 Servlet 단위에서 실행된다. 반면 AOP는 메소드 앞에 Proxy패턴의 형태로 실행된다. 실행순서를 보면 Filter가 가장 밖에 있고 그안에 Interceptor, 그안에 AOP가 있는 형태이다. 따라서 요청이 들어오면 Filter → Interceptor → AOP → Interceptor → Filter 순으로 거치게 된다.

1. 서버를 실행시켜 서블릿이 올라오는 동안에 init이 실행되고, 그 후 doFilter가 실행된다. 
2. 컨트롤러에 들어가기 전 preHandler가 실행된다.
3. 컨트롤러에서 나와 postHandler, after Completion, doFilter 순으로 진행이 된다.
4. 서블릿 종료 시 destroy가 실행된다.

Filter, Interceptor, AOP의 개념

Filter

스프링의 기능이 아닌 자바 서블릿에서 제공하는 기능(J2EE의 스펙)이다. 스프링에 들어온 요청이 DispatcherServlet에 의해 컨트롤러에 매핑되는데 Filter는 그 전, 후에 동작한다. Filter는 FilterChain을 통해 여러 필터가 연쇄적으로 동작하게 할 수 있다. ServletRequest 혹은 ServletResponse를 교체할 수 있다.

Filter는 주로 XSS방어, 인코딩 변환처리, 요청에 대한 인증, 권한 체크등을 하는데에 쓰인다. 들어온 요청이 DispatcherServlet에 전달되기 전, 헤더를 검사해 인증 토큰이 있는지 없는지, 올바른지 올바르지 않은지 등을 검사할 수 있다.

필터 클래스는 servlet의 Filter 인터페이스를 구현하여 만들 수 있다. 필터 인터페이스는 3가지 메소드를 가지고 있는데, 다음과 같다.

• init() : 필터가 생성될 때 수행되는 메소드
• doFilter() : Request, Response가 필터를 거칠 때 수행되는 메소드
• destroy() : 필터가 소멸될 때 수행되는 메소드

Interceptor

요청에 대한 작업을 DispatcherServlet과 Handler(Controller)사이에서 전/후로 가로채어 처리한다.
스프링 컨텍스트 영역 내부에서 Controller에 관한 요청과 응답에 대해 처리한다.

Filter와의 차이점은 Intercepter가 스프링의 기술이기 때문에 스프링에서 관리하는 빈들을 사용할 수 있다.

인터셉터는 여러 개를 사용할 수 있으며 로그인 체크, 권한 체크, 프로그램 실행시간 작업, 로그확인 등의 업무에서 사용가능하다. 자동으로 동작하는 기능은 거의 없고 대부분 HandlerInterceptor 인터페이스를 직접 구현하여 추가해야한다. 애플리케이션 별 커스텀 로직을 추가해야한다면 인터페이스를 구현하면 된다.

// 이런식으로 사용가능
public class AuthCheckInterceptor implements HandlerInterceptor {

    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception{
        HttpSession session = request.getSession(false);
        if(session != null){
            Object authInfo = session.getAttribute("authInfo");
            if(authInfo != null){
                return true; // 로그인 상태
            }
        }
        response.sendRedirect(request.getContextPath() + "/login");
        return false; // 로그인 상태 아님
    }
}

인터셉터의 실행메서드

• preHandler(): 컨트롤러 메서드가 실행되기 전
• postHanler(): 컨트롤러 메서드 실행직후 view페이지 렌더링 되기 전
• afterCompletion(): view페이지가 렌더링 되고 난 후

AOP

OP는 OOP를 보완하기 위해 나온 개념으로 관점 지향 프로그래밍이라 불린다. 객체 지향 프로그래밍을 했을 때 중복을 줄일수 없는 부분을 줄이기 위해 종단면에서 바라보고 처리한다.

주로 로깅, 트랜잭션, 에러 처리에 사용되며, Filter와 Intercepter와 다르게 비즈니스 로직을 처리할 때 사용된다. 메소드 전 후로 자유롭게 설정할 수 있다.

Intercepter, Filter는 주소로 대상을 구분해서 걸러내야하는 반면, AOP는 주소, 파라미터, 애노테이션 등 다양한 방법으로 대상을 지정할 수 있다.

AOP의 Advice와 HandlerIntercepter의 가장 큰 차이는 파라미터의 차이다. Advice의 경우 JoinPoint나 ProceedingJoinPoint 등을 활용해서 호출하지만, HandlerIntercepter는 FIiter와 유사하게 HttpServletRequest, HttpServletResponse를 파라미터로 사용한다.

참고링크

filter, interceptor, aop는 모두 공통적인 로직을 처리하기 위한 기능이다. 메서드 호출 전, 중간, 뒤에 추가하여 공통 로직을 자동으로 처리할 수 있다. filter는 스프링이 아닌 자바 서블릿에서 제공하는 기능이다. http 요청을 가장 먼저 받아서 처리를 하며, DispatcherServlet이 실행되기 전/후에 실행이 된다. FilterChain을 통해서 여러 필터가 연쇄적으로 동작하게 할수 있으며 주로 XSS방어, 인코딩 변환처리, 인증인가 등의 작업을 하는데 쓰인다. 스프링 컨텍스트 외부에서 동작하기 때문에 빈에 접근할 수 없다.(DelegatingFilterProxy를 사용하여 빈을 주입할 수 있음) Interceptor는 스프링 컨텍스트 내부에서 동작하며 Controller가 실행되기 전/후에 실행된다. 스프링 컨텍스트 내부에서 동작하기 때문에 빈에 접근할 수 있고 어떤 컨트롤러가 호출되는지에 따라서 로직을 다르게 적용하기 좋다. 주로 로그인/권한 확인, API 로깅 등의 작업을 처리할때 사용할 수 있다. AOP는 주로 비즈니스 로직에서 공통 로직을 분리할때 사용한다. 로깅, 트랜잭션 등을 처리할때 사용할 수 있으며 메서드 단위로 세밀하게 적용할 수 있다. interceptor와의 가장 큰 차이는 파라미터이다. interceptor는 HttpServletRequest, HttpServletResponse를 파라미터로 사용하고, aop는

filter, interceptor, aop는 모두 공통 로직을 처리하기 위한 기능이다. 가장 큰 차이점은 어느 레벨에서 동작하는지에 차이가 있다. filter는 서블릿 레벨에서 동작하기 때문에 스프링 컨텍스트 밖에서 실행된다. 따라서 빈에 접근하기 어렵고 DI같은 스프링의 편의 기능을 사용할 수 없다. interceptor는 Spring MVC 레벨에서 실행된다. Controller 실행 전/후에 동작하며 http정보와 컨트롤러 정보에 접근할 수 있다. AOP는 http와는 무관하게 메서드 레벨에서 동작하여 주로 비즈니스 로직을 처리할 때 사용된다. 따라서 전체 요청을 가로채서 인코딩, spring security와 같은 작업을 할 때는 filter를, 컨트롤러 전후로 실행되야하는 작업은 Interceptor, 비즈니스 로직에 대한 공통 로직을 처리할 때는 aop를 사용한다.

• 스프링 시큐리티가 interceptor가 아닌 filter에서 동작하는 이유? DispatcherServlet에 도달하기 전에 요청을 차단해야 하기 때문이다. 보안은 최대한 빨리 검증하는 것이 좋다. 만약 스프링 시큐리티가 interceptor에서 동작한다면 filter체인을 통과하고 DispatcherServlet가 실행된 후에 interceptor에서 인증을 할 것이다. 만약 인증이 실패한 경우에 이미 많은 리소스를 사용한 후이다. 또한 filter는 정적 리소스, 존재하지 않는 url 등등 모든 요청을 가로챌 수 있는 반면 interceptor는 스프링 mvc가 처리하는 요청만 가로챌 수 있다는 한계가 있다.(정적 리소스 요청 불가)