전페이지부터 쿠키, 세션 개념을 거쳐 로그인 기능에 필요한 개념들을 공부했다. 그런데 로그인 한 이유가 뭔가! → 비로그인 사용자는 상품 등록, 상품 수정등 다른 페이지에는 들어가면 안된다!

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

그럼 간단하게 sessionId를 요청 헤더에 담아 확인하는 로직(로그인 했는가?)을 api호출하는 초반에 넣어주면 되는거 아닌가?! 라는 생각이 든다. 아래와 같이…

    @GetMapping
    public String items(Model model) {
        //로그인 여부 체크
        List<Item> items = itemRepository.findAll();
        model.addAttribute("items", items);
        return "items/items";
    }

그래 뭐.. api 호출 함수 맨 위에다가 일괄 추가정도는 인정인데.. 만약 로그인 관련 로직이 싹 다 바뀐다면…??!?!(session기반 → jwt기반) 그럼 또 모든 로직을 한번 쳐다봐야 하는 굉장히 좋지 않은 코드가 되버린다!

이러한 공통 관심사는 스프링 AOP로도 해결이 가능하겠지만, 웹과 관련된 공통 관심사는 앞으로 설명할 서블릿 필터나 스프링 인터셉터를 이용하는 것이 좋다! 왜냐? 웹과 관련된 공통 관심사를 처리하려면 HTTP 헤더나 URL에 대한 정보가 필요한데 서블릿 필터나 스프링 인터셉터는 HttpServletRequest를 제공하기 때문에!!

필터는 한줄로 정리하자면 서블릿이 지원하는 수문장이다.

필터의 흐름은 아래와 같다

HTTP 요청 -> WAS -> 필터 -> 서블릿(DispatcherServlet) -> 컨트롤러

요청이 WAS로 들어온다음 필터가 있다면 꼭 필터가 호출 된 다음 서블릿이 호출된다. 참고로 필터는 특정 URL패턴에 적용할 수 있기에 /* 로 설정하면 모든 요청에 대한 필터를 적용시킬 수 있을 것이다!(모든 요청에 대한 로그를 남겨주세요! 하면 필터에 로그 로직 쓰면 되겠다!)

그래서 아래처럼 다른 api를 호출할 때 로그인 여부를 확인하기 딱 좋다~!

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