스터디원과 스프링 시큐리티 필터에 대해 이야기 하다 필터와 인터셉터의 차이, 그리고 필터의 조금더 깊은 이해를 얻어서 작성해본다. 그리고 추가적으로 이 둘과 비슷한 AOP에 대해서도 조사하여 공부하였다.

공통 기능

스프링을 사용해서 개발을 하다보면 인증(로그인), 인가(권한), 로깅, 트랜잭션 등 공통적으로 처리해야하는 작업들이 발생하는데, 이때마다, 코드를 반복해서 작성해야 한다면, 중복되는 코드가 많아지고, 유지보수가 힘들어 진다.

메서드를 호출하기 전, 후에 공통된 로직을 호출 할 수 있는 방법은 제목과 같이 filter, intercepter, AOP 세가지가 있다.

Filter

먼저 필터는 스프링의 기능이 아니기 때문에 스프링 밖에서 동작하며 디스패쳐 서블릿 앞에서 동작하게 된다. 때문에 request는 디스패쳐 서블릿에 의해 다뤄지기 전, 다뤄진 후에 동작하게 된다. 또한 필터체인을 통해 여러 필터가 연쇄적으로 동작한다.

필터는 주로 스프링 시큐리티에서 요청에 대한 인증 인가등을 검증하는 데 사용된다.

개인적으로도 프로젝트에서 Spring Security와 JWT를 사용해서 인증과 인가를 구현한 경험이 있다.링크

여기서 내가 이 글의 시작이었던 궁금증이 있는데 필터는 디스패쳐 서블릿 밖에 있어서 WebApplicationContext 밖에 있는데 어떻게 인증 정보를 컨텍스트 내부로 전달해 주는지 이해가 안되었었다.

그래서 스터디원과 스터디를 한 결과 얻은 것은 SecurityContext에 인증 정보가 저장되는데 이 컨텍스트를 SecurityContextHolder가 감싸서 ThreadLocal에 저장하기 때문에 SecurityContextHolder를 통하면 애플리케이션 에서 접근이 가능했던 것이었다.

Intercepter

인터셉터는 디스패쳐 서블릿 뒤와 컨트롤러 사이에서 요청 응답을 낚아챈다!

인터셉터는 필터와는 다르게 디스패처 서블릿 뒤에서 동작하고, 스프링의 기능이기 때문에 Bean들을 사용할 수 있다. 위에서 말 못했지만 반대로 말하면 필터에서는 스프링 Bean을 사용할 수 없다.

아직 인터셉터를 사용한 경험은 없는데, 주로 필터보다 세부적인 보안, 인증/인가, API호출에 대한 logging, 데이터의 가공등에 사용된다고 한다.

AOP

관점지향 프로그래밍. OOP에서는 할 수 없었던 중복 제거를 위한 프로그래밍 기법이다. 중복을 줄이기 위해 요청이 종으로 움직일때 AOP는 횡으로 코드를 바라본다.

Spring AOP를 써본적은 없지만 AOP기능을 많이 사용해본 기억이 있다. 그건 바로 @Transactional이다. 엔티티의 lazy loading을 걸어놓은 멤버에 접근할때 @Transactional을 사용하므로써 정상적으로 접근하기 위해 사용했던 기억이 있다.

세가지에 대해 간단하게 알아봤는데, 각각 하나씩 더 자세히 사용해보며 알아보는 기회를 갖으면 좋을것 같다.