[Spring] Filter & Interceptor

0. Filter, Interceptor

웹 개발을 하면서 공통으로 처리해야할 작업들이 있다. 특히 지금 구현하고 있는 로그인 관련이 그렇다. 그래서 공통으로 처리해야 할 작업들을 하기 쉽게 나온 방법들인 인터셉터, 필터, AOP에 대해서 정리하려고 한다.  

 

애플리케이션 여러 로직에서 공통으로 관심이 있는 있는 것을 공통 관심사(cross-cutting concern)라고 한다. 이러한 공통 관심사는 스프링의 AOP로도 해결할 수 있지만, 서블릿 필터 또는 스프링 인터셉터로 해결 할 수 있다. 

 

 

 

1.  Filter(필터)

• 서블릿 필터는 DispatcherServlet 이전에 실행이 되는데 필터가 동작하도록 지정된 자원의 앞단에서 요청내용을 변경하거나,  여러가지 체크를 수행할 수 있다. 보통 인코딩 처리가 여기에 해당한다. 

HTTP 요청 -> WAS -> 필터 -> 서블릿 -> 컨트롤러 //로그인 사용자

HTTP 요청 -> WAS -> 필터(적절하지 않은 요청이라 판단, 서블릿 호출X) //비 로그인 사용자

 

 

 

2. Interceptor(인터셉터)

• 컨트롤러가 요청을 처리하기 전/후로 가로챈다고 보면 된다.
• 로깅 모니터링 정보 수집, 접근 제어 처리 등의 실제 비지니스 로직과는 분리되어 처리해야 하는 기능들을 넣고 싶을 때 유용함. 
• 여러개 설정 할 수있으나 순서가 중요함. 
• 필터는 스프링 컨텍스트 외부에 존재하여 스프링이랑 무관하지만 인터셉터는 DS 에서 컨트롤러 사이에 존재하며 스프링 컨텍스트 내부에 존재한다. 
• 로깅 모니터링 정보 수집, 접근 제어 처리 등의 실제 비지니스 로직과는 분리되어 처리해야 하는 기능들을 넣고 싶을 때 유용함. 
• 여러개 설정 할 수있으나 순서가 중요함. 

HTTP 요청 -> WAS -> 필터 -> 서블릿 -> 스프링 인터셉터 -> 컨트롤러 //로그인 사용자

HTTP 요청 -> WAS -> 필터 -> 서블릿 -> 스프링 인터셉터(적절하지 않은 요청이라 판단, 컨트롤러 호출 X) // 비 로그인 사용자

 

요구사항: 로그인 하지 않은 사용자는 들어갈 수 없게 한다. url을 쳐도 들어갈 수 없게 한다. 

그런데 인터셉터로 구현한 이 기능 스프링 시큐리티에서도 제공하지 않나?