필터는 서블릿이 제공
인터셉터는 스프링이 제공
예를 들자면 회원정보수정이나 이런 것들은 로그인 한 사용자만 들어올 수 있도록 해야 한다.
근데 지금은 링크태그를 안달아놔서 그렇지, 그냥 url에 치면 들어올 수 있다.
말 그대로 필터이다. 특정 조건을 만족하는 사용자만이 특정 url에 접근할 수 있도록 하는 것이다.
물론 회원정보 수정 등 컨트롤러의 로직에 일일히 다 쿠키검사를 하는 방법도 있겠지만..
한 두개가 아닐 것이다.
게다가 만약 향 후 로그인에 관한 로직을 수정하게 된다면..
이렇게 여러 로직들에서 공통적으로 관심을 가져야 하는 것을 공통 관심사 라고 한다.
회원 정보 수정, 삭제, 조회 등 사용자에 대한 로그인(인증)에 관심이 있다.
AOP( https://qwefdg3.tistory.com/89 )를 써도 해결할 수 있다고 하지만,
웹과 관련한 공통 관심사는 서블릿 필터나 스프링 인터셉터를 쓴다고 한다. (보통 웹의 공통 관심사는 헤더의 정보나 url의 정보가 필요할 여지가 있기 때문.)
필터는 서블릿이 지원하는 수문장이며, 필터를 포함한 HTTP 요청의 흐름은 다음과 같다.
HTTP 요청 -> WAS -> 필터 -> 서블릿(디스패쳐서블릿) -> 컨트롤러
즉, 프론트 컨트롤러를 거치기도 전에 동작한다. 필터는 하나의 로직으로, 우리가 만드는 거다.
이렇게 디스패쳐 서블릿을 거치기 전에 동작하기 때문에, 필터에서 걸러지면(반대되면) 아예 디스패쳐서블릿을 호출하지 않게도 할 수 있다.
그리고 또 이건 체인구성이 가능하다.
즉, 여러 필터를 검사할 수 있다.
HTTP 요청 -> WAS -> 필터1 -> 필터2 -> ... -> 서블릿 -> 컨트롤러.
그리고, 필터라고 해서 뭔가 거른다는 느낌이 강하지만,
그냥 컨트롤러 가기 전 뭔가 하고 싶은 로직을 한다고 생각해도 된다.
예를 들자면 누가 웹서버에 요청을 한다면 그 요청에 대한 로그를 남기게끔 하고 싶다던지.
public interface Filter {
public default void init(FilterConfig filterConfig) throws ServletException {}
public void doFilter(ServletRequest request, ServletResponse response,
FilterChain chain) throws IOException, ServletException;
public default void destroy() {}
}
이게 실제 서블릿이 제공해주는 필터의 인터페이스다.
중요한 것은 doFilter이다.
인자로 우리가 HttpServletRequest, Response를 받을 수 있다.
FilterChain은 아마 다음에 실행할 필터가 아닐까 한다.
저 doFilter에 우리가 필터할 로직을 쓰고,
모든 필터 체인을 통과한다면 그제서야 DispatcherServlet에 도달하여 DispatcherServlet이 실행된다.
이 인터페이스를 구현하고 등록하면,
서블릿 컨테이너가 알아서 필터를 싱글톤 객체로 생성하고 관리해준다.
init() : 필터 초기화 메소드. 서블릿 컨테이너가 생성될 때 호출.
doFilter() : 요청이 들어올 때 호출되는 우리가 필터 로직을 담아야 할 공간.
destroy() : 필터 종료 메소드. 이건 아예 서블릿 컨테이너가 종료될 때 호출되는거임.
'스프링 > 4. 스프링 MVC-2' 카테고리의 다른 글
56. 인증 체크 필터 구현 (0) | 2023.09.09 |
---|---|
55. 필터 구현 (0) | 2023.09.09 |
53. 세션 정보 확인과 타임아웃 설정 (0) | 2023.09.07 |
52. 스프링 세션 업그레이드 (0) | 2023.09.07 |
51. 스프링의 Http 세션 (0) | 2023.09.07 |