이번 강의에서는
우리가 커스텀 필터를 생성하고자 할 때마다
사용할 수 있는 다른 옵션들은 어떤 것이 있는 지
살펴보고자 합니다
지금까지 이전 강의에서는
필터라는 인터페이스를 구현하고자 했습니다
그리고 필터를 구현할 때는
비즈니스 로직을 doFilter 라는 메소드를
오버라이딩 하여 작성하는 것을 강조했습니다
그러나 필터 인터페이스 외에도
Spring 프레임워크를 사용할 때
다른 고급 옵션들이 있습니다
첫 번째 옵션은 GenericFilterBean 입니다
이는 추상(abstract) bean 클래스입니다
두 번째 옵션은
OncePerRequestFilter 입니다
커스텀 필터를 작성하고자 할 때
어떤 상황에서 우리가 이러한 클래스를
사용할 수 있는지 이해해 봅시다
여기서 우리는 먼저 GenericFilterBean를 열어야 합니다
이것은 Spring 프레임워크 내에서 사용 가능한
추상 클래스(abstract class) 입니다
이 추상 클래스 또한 스스로
필터를 실행시킴을 볼 수 있습니다
그러나 저의 커스텀 필터 안에
GenericFilterBean이
얻는 이점은 무엇일까요?
이 클래스에 대한 주석을 읽어 봅시다
이 클래스는 필터 인터페이스의 간단한 기본적인 구현이며
모든 유형의 필터에 대해 편리하고 좋은 클래스 입니다
GenericFilterBean 를 활용하고자 할 때마다
얻을 수 있는 장점은
web.xml이나 배포 설명자 내에서
구성한 모든 설정 매개변수, 초기 매개변수 및
서블릿 컨텍스트 매개변수의
세부 정보를 제공한다는 것입니다
그러니까 만약에
커스텀 필터 내에서
이러한 구성 매개변수, 초기 매개변수
또는 서블릿 컨텍스트에 접근해야 되는 시나리오가 있다면
이 추상 클래스를 활용할 수 있습니다
이 추상 클래스 내에서
사용 가능한 메소드를 살펴보면
환경 세부 정보, 필터 구성 세부 정보
서블릿 컨텍스트 세부 정보 및
초기 매개변수를 제공하는 여러가지의 메소드가 존재합니다
이러한 세부정보는 보통
배포 서술자 내에서 정의하기에
이 추상 클래스에서는 쉽게 사용할 수 있습니다
이 방법으로 이러한 매개변수를
읽기 위한
비즈니스 로직을 모두 작성할
필요가 없습니다 이 경우는 GenericFilterBean을 활용하시기 바랍니다
항상 권장하는
두 번째 흥미로운 추상 클래스는
OncePerRequestFilter 입니다
커스텀 필터를 만들고
해당 필터를 Spring Security FilterChain에
구성하려고 할 때
기본적으로 Spring Security 또는 Spring 프레임워크는
해당 필터가 요청 당 한 번만
실행된다고 보장하지 않습니다
여러 이유로 서블릿 컨테이너가
필터를 여러 번 호출할 수 있는 상황이 발생할 수도 있습니다
그러나 필터가 반드시
요청 당 한 번만 실행되어야 하는 경우에는
이 추성 클래스를 확장하여
커스텀 필터를 정의해야 합니다
그 추상 클래스가 바로 OncePerRequestFilter 입니다
OncePerRequestFilter 라는 이름도
이 필터가 각 요청에 대해서
반드시 한 번만 실행되도록
보장한다는 것을 의미합니다
이 필터가 어떻게 이것을 수행하는지
확인하려면
이 OncePerRequestFilter의 doFilter 메소드 내부를 살펴보면
필터가 이미 실행되었는지의 여부를
결정하기 위해 필요한 많은 로직이 있습니다
만약 이것이 이미 실행되었다면
단순히 필터를 호출하지 않고 진행합니다
그래서 특정 시나리오에서는
커스텀 필터를
호출하지 않고 진행하고자 합니다
필터를 건너 뛰고 한 번만 실행되도록 하는
모든 로직이
이 doFilter 메소드 내에 정의되어 있습니다
그러나 여기서 질문이 있을 수 있습니다
만약 OncePerRequestFilter가 이미
doFilter 메소드를 오버라이드하여 구현 했다면
저만의 비즈니스 로직은 어디에 정의해야 될까요?
이전에 우리는 doFilter 메소드 내에
우리의 모든 비즈니스 로직을 작성했습니다
돌아가서 우리가 정의했던 필터 중 어느 것을 확인하든
우린 비즈니스 로직을
doFilter 메소드 내에 적었습니다
그러나 이번 OncePerRequestFilter 시나리오에서는
상황이 다릅니다
이번에는
모든 비즈니스 로직을
doFilterInternal 이라는 메소드에 적는 것을 명심해야 합니다
따라서 이 doFilterInternal 은 추상 메소드입니다
오버라이드 하고 모든 자신의 로직을 적는 것도 가능합니다
내부적으로 OncePerRequestFilter 는
한 번의 요청 당 이 메소드를 호출하도록 관리하려고 노력합니다
또한 이 필터에는 다른 유형의
유용한 메소드가 있습니다
예를 들어서
shouldNotFilter 이라는 메소드가 있습니다
어떤 이유에서인지 web API나 일부 REST API 경로에 대해
이 필터를 실행하고 싶지 않다면
해당 세부 정보를 정의하고
false 값을 반환하는 대신에
조건에 따라 true를 반환할 수 있습니다
return false가 기본 동작으로 설정이 되어 있고
실행하고자 하는 커스텀 필터는
각 요청 당 한 번씩만 호출됩니다
이러한 예외적인 필터링 시나리오가 있을 상황에서는
OncePerRequestFilter 내부의
유용한 메소드를 사용할 수 있습니다
여기서 물어보면 만약 이 OncePerRequestFilter를 활용하는
Spring Security 필터가 있는지 확인하고 싶다면
당연히 우리가 좋아하는 필터인
BasicAuthenticationFilter를 확인할 수 있습니다
이 BasicAuthenticationFilter 를 열어보면
이것이 OncePerRequestFilter를 확장시키고
그렇게 확장 시킴으로서
모든 로직을
doFilterInternal 에서 정의해야 됩니다
여기에서 자격 증명을 추출하고
UsernamePasswordAuthenticationToken 의 객체를 생성하는
모든 로직이 doFilterInternal 메소드 내에서
정의 되어 있음을 확인할 수 있습니다
이것이 바로 여러분이 가능하다면
OncePerRequestFilter를 사용할 것을 권장하는 이유입니다
여러분은 이전에 만든 모든 커스텀 필터에 대해
왜 OncePerRequestFilter를 사용하지 않았는지
의문을 가질 수도 있습니다
이것은 의도적으로 그렇게 한 것이며
여러 가지의 다른 접근법을 보여주기 위함입니다
저는 JWT 토큰(Token)과 같은
심화 주제에 관해 다음 섹션에서 이야기를 나눌 때
당연히 OncePerRequestFilter 를 사용할 것입니다
그때 확실히 저는 여러분에게
OncePerRequestFilter에 대한
모든 개념을 상기시키고
이로써 Spring Security 프레임워크 내에서
필터에 관한 모든 내용을 살펴보았습니다
저는 여기서
GitHub 리포지터리를 강조하고 싶습니다
GitHub 리포지터리에서
section8 을 확인하시면
Spring Security에서 필터를 탐색하는 주석을 찾을 수 있습니다
그 secion8에는
우리가 논의한 변경 사항을 모두 반영한
Maven 프로젝트를 업로했습니다
어떤 질문이든 있다면 이것을 참조해주십시오
이것으로 저는 Spring Security 내의 필터의 개념에 대해
여러분이 매우 명확히 이해했을 것으로 생각합니다
하지만 이 섹션은 아직 끝나지 않았습니다
다음 강의에서 하나 더 중요한 주제를 논의해보고자 합니다
그 다음에 이 섹션을 마무리 짓겠습니다
감사합니다 다음 영상에서 뵙겠습니다