본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.
안녕하세요 :)
오늘은 챌린지 39일차로, 벌써 돌아온 불금입니다. 시간 너무 빨라요ㅠㅠ
오늘 배울 내용은,
Part B. 스프링 시큐리티 심화
Ch 4. 사전 및 사후 권한 부여/필터링
"06. spring-data-jpa 와 필터링" 입니다.
오늘은 PreFilter 와 PostFilter 를 다시 알아보는 시간을 가지면서, Spring-Data-Jpa와 필터링에 대해 배웠다. 이전 시간에서는 @PreFilter 와 @PostFilter 에 대해 알아보았고, 예제에서는 별다른 이슈가 없지만 실무에서는 문제가 발생할 수 있다는 것도 알 수 있었다.
이미 알고 있는 배열/컬렉션에 대해 필터링을 할 때에는 @PreFfilter 를 사용하면 되고 이는 큰 문제가 되지 않는다. 하지만 @PostFilter 는 어떨까? PostFilter 를 사용하기 위해서는 인증된 사용자 정보와 전체 리스트가 필요하다. 따라서 findAll() 등의 메소드로 전체 리스트를 가져오게 될텐데, 실무 수준에서는 그 데이터의 양이 엄청나다. 경우에 따라 OOM (Out Of Memory) 가 발생할 수도 있고, 성능 관점에서는 아주 비효율적인 방법이다. 그러면 어떤 방법으로 비슷한 구현을 할 수 있을지 고민해보자.
첫 번째 예시로는 @PostFilter 를 활용하여 첫 번째 애플리케이션을 구현하는 것으로 findAll() 이후 @PostFilter 적용한다.
두 번째 예시로는 조회 쿼리에 조건을 추가하여 애플리케이션을 구현하는 것으로 @Query 활용한다.
의존성은 jpa, spring security, web, spring-security-data, mysql-connector-j 추가하였고, Docker-compose.yml 파일은 docker-compose 파일 기반으로 MySQL 데이터베이스 설정하고, application.yml 파일은 데이터소스, jpa 관련 설정을 application.yml 에 추가하였고, JpaConfig 클래스로 데이터소스를 설정하였고, data.sql & schema.sql 은 contents 테이블 생성 및 컨텐츠 데이터 생성 SQL을 활용하였고, Entity 는 Content 를 위한 엔티티 생성했고, ContentRepository 는 첫 번째 예시에서는 Repository 메소드 자체에서 조회한 결과값에 바로 @PostFilter를 적용하여 처리했다. 두 번 째 예시에서는 @Query 어노테이션으로 쿼리를 직접 수행하여 where 조건에 authentication.name 조건으로 검색했다. spring-security-data 는 해당 기능이 동작하려면 아래 의존성과 설정이 필요하다. 보안 설정은 danny 와 steve 두 명의 사용자를 등록했고, ContentService 는 ContentV1Repository 와 ContentV2Repository 에 대한 의존성 주입을, ContentController 에서는 GET /api/v1/contents/{name} 엔드포인트 => 첫 번째 예시 / GET lapi/v2/corents/{name} 엔드포인트 => 두 번째 예시 로 진행했다.
애플리케이션을 실행하여 데이터를 확인해보니 첫 번째 예시 : 정상 동작 / 두 번째 예시 : 정상 동작 / 세 번째 예시 : 정상 동작 하는 것을 알 수 있었다. 성능 상으로 봤을 때는 두번째 방식으로 동작하는 것이 성능 과정에서 이득이 많다는 것을 알고 있으면 될 것 같다. 그리고 가능하다면 데이터를 많이 넣어서 테스트 해보는 것도 좋을 것 같다.
