jwt를 이용할 때, 혹은 로그인 기능을 이용할 때 대부분 스프링 시큐리티를 사용하곤 한다.
스프링 시큐리티에 대한 자세한 공부를 하기 전에 filter에 대한 공부를 하고 들어가려 한다.
(왜냐하면 스프링 시큐리티가 필터 체인을 이용하는 것으로 어렴풋이 알고 있다.)
필터 혹은 인터셉터를 사용해서 로그인을 한 사용자와 로그인을 하지 않은 사용자를 미리 분리하려 한다.
로그인을 하지 않은 사용자가 호출하면 안되는 컨트롤러를 접근하는 것을 미리 막기 위함이다.
이 작업을 각각의 컨트롤러의 모든 메서드에서 구현한다는 것은 매우 귀찮고 복잡한 일이다.
또한 이는 모든 API의 공통 관심사이기 때문에 AOP를 통해 해결할 수도 있지만, HttpServletRequest나 HttpServletRespone 객체가 사용되는 웹과 관련한 공통 관심사는 필터나 인터셉터를 사용하는 것이 바람직하다. (해당 객체를 지원하기 때문)
필터의 흐름은 위와 같다.
Dispatcher Servlet이 호출되기 이전에 필터를 먼저 거치게 된다.
서블릿이 지원하는 필터에는 위의 세가지 메서드가 있다.
핵심 메서드는 doFilter이다.
우리가 필터를 여러개 등록했다면, 다음 필터를 호출하고, 더이상 필터가 존재하지 않으면 Dispatcher Servlet을 호출하는 구간이다.
모든 요청에 대하여 로그를 남기는 간단한 필터를 예시로 구현해보았다.
필터를 등록하면 싱글톤 객체로 스프링이 보관하게 된다.
위의 필터는 모든 url 요청에 대해 첫번째로 적용되는 필터임을 나타낸다.
"/api/v1/members"라는 멤버등록 요청에 대한 로그이다.
아래는 에러가 발생했을 때의 로그이다.
필터의 흐름을 알았으니 로그인 필터를 만들어보자.
우선 로그인 필터는 세션에 대해서, 세션값이 있는지 없는지를 확인하도록 하겠다.
Filter의 init이나 destroy 메서드는 default로 구현되어 있기 때문에 따로 커스터마이징 하지 않고, doFilter 메서드에만 집중하도록 하겠다.
session이 아예 없거나, "loginId"라는 이름의 값이 없는 경우는 로그인하지 않은 사용자로 간주하여 에러를 띄운 뒤 다음 필터나 서블릿을 호출하지 않고 종료하도록 하게 했다.
isLoginCheckPath라는 메서드를 만들어서, 해당 url 요청이 로그인 여부를 확인해야하는 요청인지 판별할 수 있도록 했다.
그리고 WebConfig 클래스를 통해 filter를 등록해주었다.
다음은 토큰을 검증하는 필터이다.
세션을 검증하는 필터와 유사한 방식으로 구현하여 필터에 등록해주었다.
