[로그인] Servlet Filter

1. 공통 관심사항.

---

• 로그인 한 사용자만 상품 관리 페이지에 들어갈 수 있어야 한다.
• 하지만 로그인 하지 않은 사용자도 다음 URL을 직접 호출하면 상품 관리 화면에 들어갈 수 있다 ㄷㄷ
• 어떻게 막지??
• 각 컨트롤러에서 로그인  여부를 체크하는 메서드를 추가하면 되긴 한다.
• 하지만 모든 로직에다가 추가해야 하고,
• 새로운 로직이 만들어지면 또 적용해야하고
• 유지보수도 어려워진다.

• 이렇게 애플리케이션 여러 로직에서 공통으로 관심이 있는 있는 것을 
• 공통 관심사(cross-cutting concern)라고 한다. 
• 여기서는 등록, 수정, 삭제, 조회 등등 여러 로직에서 공통으로 인증에 대해서 관심을 가지고 있다.

 

• 스프링의 AOP로도 해결할 수 있지만, 
• 웹과 관련된 공통 관심사는 지금부터 설명할 서블릿 필터 또는 스프링 인터셉터를 사용하는 것이 좋음.
• 웹과 관련된 공통 관심사를 처리할 때는 HTTP의 헤더나 URL의 정보들이 필요한데, 
• 서블릿 필터나 스프링 인터셉터는 HttpServletRequest 를 제공한다.

 

2. Servlet 필터

---

• 필터는 Servlet이 지원하는 수문장 ㅋㅋㅋ 
• 필터의 흐름
  • HTTP 요청 -> WAS -> 필터 -> 서블릿 -> 컨트롤러
  • 필터를 적용하면 필터가 호출 된 다음에 서블릿이 호출된다.
  • 모든 고객의 요청 로그를 남기는 요구사항이 있다면 필터를 사용하면 된다
  • 참고로 필터는 특정 URL 패턴에 적용할 수 있다
    • 이 url일  때 이 필터 실행해줘!!
  • 예를들어  /* 라고 하면 모든 요청에 필터가 적용된다.
  • Servlet = Dispatcher Servlet
• 필터 제한
  • ex) 로그인 한 사용자만 controller호출해줘 
  • 로그인 사용자 : HTTP 요청 -> WAS -> 필터 -> 서블릿 -> 컨트롤러
  • 비 로그인 사용자 : HTTP 요청 -> WAS -> 필터(적절하지 않은 요청이라 판단, 서블릿 호출X)
  • 필터에서 적절하지 않은 요청이라고 판단하면 거기에서 끝낼 수 있음..
  • 따라서 로그인 여부를 체크하기 용이함
• 필터 체인
  • 필터를 여러개 꽂을 수 있음.
  • HTTP 요청 -> WAS -> 필터1 -> 필터2 -> 필터3 -> 서블릿 -> 컨트롤러
  • 필터는 체인으로 구성되는데, 중간에 필터를 자유롭게 추가할 수 있다. 
  • ex) 로그를 남기는 필터 -> 로그인 여부를 체크하는 필터

 

3. 필터 인터페이스

---

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() {}
  }

• 필터 인터페이스를 구현하고 등록하면 
• 서블릿 컨테이너가 필터를 싱글톤 객체로 생성하고, 관리함
• init(): 필터 초기화 메서드, 서블릿 컨테이너가 생성될 때 호출된다.
• doFilter(): 고객의 요청이 올 때 마다 해당 메서드가 호출된다. 필터의 로직을 구현하면 된다.
• destroy(): 필터 종료 메서드, 서블릿 컨테이너가 종료될 때 호출된다.