Spring Security - Filter, OncePerRequestFilter 정리해보자

Filter | OncePerRequestFilter

 가볍게 필터가 어떻게 동작하는지 그림을 통해서 확인해보자

 

그럼 흔히 중간에서 우리의 동작들을 제어해주는 FIlter, Interceptor의 차이를 확인해보자

 

우선 Filter은 DispatchServlet 앞에서 동작하는 큰 문이고, Interceptor은 DispatchServlet과 Controller 사이에서 동작하는 작은 문이다.

 

필터

• Web Application Context의 기능
• 인코딩, Cors, Log, 인증, 권한 등을 구현

인터셉터

• 스프링의 Spring Context의 기능 Bean같은 느낌
• 스프링 컨테이너로 다른 빈을 주입하여 사용하기 용이하다.
• 다른 빈을 활용하여 인증, 권한 등을 구현 할 수 있다.

 

프로젝트를 진행하면서 Filter extends OncePerRequestFilter를 통해서 진행하고 있었다.

 

그럼 위의 OncePerRequestFilter은 무엇일까

 

우선 필터의 동작 방식을 생각해보면

하나의 서블릿을 실행하는 동안 다른 서블릿에 대한 다른 요청이 들어올 수 있다. 이때 다른 서블릿에도 같은 필터가 존재한다면 그 필터가 또 실행된다. 그럼 필터가 중복으로 실행 되는데 이는 리소스 낭비를 하는 상황이 발생한다.

OncePerRequestFilter은 이를 방지해준다.

해당 요청에 대해서 이 필터는 한 번만 실행 되는것을 지정한다.

공식 문서에서 Single execution per request dispatch, on any servlet container 부분이 눈에 들어온다.

이는 우리가 OncePerRequestFilter을 통해서 동일한 request안에서는 필터링을 한번만 할 수 있게 도와준다.

 

위의 기능으로 인증, 인가를 거치고 url로 포워딩하면, 포워딩 요청의 인증 인가필터를 다시 거치지 않고 다음 로직을 바로 실행하게 해준다.

 

https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/web/filter/OncePerRequestFilter.html

OncePerRequestFilter (Spring Framework 6.0.3 API)

 

+) 번외

Filter을 제작 하면서 프로젝트 실행 URL까지 무사히 진행 되지만 프로젝트 리소스에 접근하지 못하는 상황이 잠시 발생했었다.

Controller - Service에 접근하지 못하는 상황. 코드를 확인해보니 doFilterInternal에서 doFilter을 진행하지 않은것이다.

doFilter을 사용하지 않으면 무슨 일이 일어나는 걸까?

filterChain.doFilter(request, response)를 하지 않는 행위는 다음 filter/resource를 불러오지 않겠다는 말이다.

 

---