10/31 TIL | HandlerInterceptor란?

이번 강의에서는 HandlerInterceptor가 등장했다. 오늘의 TIL은 HandlerInterceptor가 대체 무엇을 하는 놈인지 정리해보려고 한다.

---

일단 강의의 어떤 시점에 등장하였는지 먼저 말해보자면... 홈 화면에 접속하여 어떤 Token을 보내면 그 사용자에 맞는 이름을 홈 화면에 출력하게 만들려고 하면서 등장하였다. @RequestAttribute를 사용해서 user의 정보를 받고, user가 없으면 기본적으로 "Hello, world!", user가 있으면 "Hello, {유저 이름}"을 출력하려 하고자 한다.

하여 위와 같은 코드로 구현을 하였고, 아래와 같은 테스트를 돌린다.

헌데 Missing request Attribute라는 에러를 반환한다. 이는 Controller의 액션이 호출되기 전에 뭔가가 실행되어야 하는 것을 의미한다!

이때 HandlerInterceptor가 등장한다! HandlerInterceptor는 스프링 프레임워크에서 제공하는 기능인데, URI의 요청, 응답 시점을 가로채서 전&후 처리를 하는 역할을 한다. 강의 코드에서는 Controller의 액션이 호출되기 전에 이 HandlerInterceptor가 먼저 가로채서 attribute에 user 정보를 넣어주는 것이다!

그래서 HandlerInterceptor를 implements한 AuthenticationInterceptor를 위와 같이 만들어주고!

생성된 Interceptor를 사용하기 위한 WebJavaConfig라는 Configuration 클래스를 만들어 해당 인터셉터가 사용되게 한다! 물론 이렇게 작성한다고 정상 동작하지는 않는다. userRepository, jwtUtil 필요한 요소들이 추가되어야 구현을 완료하지만 오늘 TIL에서는 대략적으로 HandlerInterceptor를 왜 사용하는지, 언제 필요한지, 그리고 어떻게 사용하는지의 맥락을 파악하기 위해서 이렇게만 작성해본다.

추가적으로 Interceptor 시점에 스프링의 Context와 Bean에 접근할 수 있다. 또 이와 비스무리하게 Filter와 AOP라는 것이 있는데, 우선 Filter는 스프링 프레임워크와 무관하게 동작하는 기능이다. 보통 인코딩, XSS 방어 등의 용도로 이용되며, AOP는 주로 비지니스 로직에서 실행되는 기능으로, 로깅이나 트랜잭션 처리 등 중복 코드가 발생할 경우 중복을 줄이기 위해 사용하며, 메서드 처리 전후 지점에 자유롭게 설정이 가능하다. 이 셋의 흐름은 아래와 같다.

Interceptor, Filter, AOP의 흐름