본문 바로가기

전체 글196

@BeforeEach vs @BeforeAll - 한 테스트 클래스에 여러 개의 테스트가 있으면 반드시 동시에 돌려봐야 하는 이유 / @TestInstace 테스트를 하기 전에, 뭔가 밑작업을 해놓고 싶을 수 있다. 그 때 사용하는 대표적인 애너테이션 두 개가 바로 @BeforeEach와 @BeforeAll이다. 이름만 봐도 알 수 있듯이, @BeforeEach는 각 테스트 메서드가 수행되기 전에 매 번 수행되고, @BeforeAll은 전체 메서드가 수행되기 전에 한 번 수행된다. 이번에 Spring Security 통합 테스트를 진행하면서, @BeforeAll을 사용해 볼 기회가 생겨 기록으로 남긴다. 기존에 사용하던 테스트 set up 코드는 아래와 같았다. @BeforeEach void setUp(){ String email = "jk@gmail.com"; String password = PasswordEncoderFactories.createDeleg.. 2023. 12. 8.
Pull Request 022. 사용자 인증 및 권한 확인 기능 TDD로 구현하기 - Spring Security 설정 마무리 지난 글에서 사용자 로그인 기능까지 마무리했다. 이번에는 사용자 인증 기능을 구현하면서 Spring Security 적용을 마치고자 한다. 물론, 이후 로그아웃 구현에서 또 등장하긴 하겠지만... 아무튼 귀찮은 설정은 끝난다. 일단은 테스트 먼저 작성해보자. 테스트하고자 하는 점은 다음과 같다. 인증되지 않은 사용자도 조회는 가능하다. 그러나 게시글이나 댓글의 작성, 수정, 삭제는 불가능하다. 인증된 사용자는 위의 모든 기능의 이용이 가능하다. 해당 조건을 테스트하기 위해서는 세 가지 부분을 테스트해야 한다. 인증되지 않은 사용자가 조회 요청을 보냈을 때 조회가 가능해야 한다. 인증되지 않은 사용자가 등록 요청을 보냈을 때 거절되어야 한다. 인증된 사용자가 등록 요청을 보내면 수락되어야 한다. 이제 테스.. 2023. 12. 7.
테스트를 실행은 하고 싶은데 빌드에서는 제외하고 싶을 때 통합 테스트를 진행하면서 가장 걱정되는 부분은 배포 및 배포 자동화를 진행했을 때는 이 테스트들이 수행되면서 데이터베이스를 건들 것 같다는 점이었다. 또한 통합 테스트 메소드가 많아지면 많아질 수록 빌드에는 더욱 많은 시간이 들어갈 것이었다. 그렇다고 통합 테스트를 해보지 않을 수도 없었다. Spring Security가 잘 적용되는지를 알아봐야했다. 따라서 빌드에서는 해당 테스트를 빼고, 대신 테스트가 수행되게는 하고자 시도해봤다. 가장 먼저 수행해 본 방법은 build.gradle에서 아예 해당 테스트가 빌드에서 빠지게 설정한 방법이었다. 이렇게 설정하고 테스트를 수행하니 다음과 같은 결과가 나왔다. 우리가 수행하는 test는 기본적으로 gradle 기반으로 수행된다. 그런데, gradle빌드에서 해.. 2023. 12. 7.
[12/6 TIS] @AuthenticationPrincipal 사용기 - null 해결법 사실 저 애너테이션을 너무너무 써보고 싶었다. 부트캠프에서 프로젝트를 진행할 때부터, 저 애너테이션으로 사용자 정보를 한 번에 가져올 수 있다면 얼마나 좋을까 생각했다. 왜? 나는 안되니까... 정말 많은 글들에서 Spring Security를 적용하면 해당 애너테이션을 통해 사용자 정보를 가져올 수 있다고 한다. 그런데 내가 하면 안됐다. 정확히는 넘어와야 할 객체가 항상 null이었다. 오늘은 이 문제를 해결하고 직접 사용해보자. @PostMapping public ResponseEntity postFreeBoard(@AuthenticationPrincipal Member writer, @RequestBody FreeBoardDto.Post dto) { FreeBoardDto.Response resp.. 2023. 12. 6.
Pull Request 021. 로그인 기능 TDD로 구현하기 - Spring Security / JWT 적용하기 인증 / 인가 처리를 위해 선택할 수 있는 방법은 다양하다. 모든 필터 레벨에서 일어나는 일을 직접 처리할 수도 있고, OACC같은 프레임워크를 사용할 수도 있다. 인증을 위해 쿠키를 이용하거나 세션을 이용할 수도 있다. 나는 Spring Security 프레임워크를 활용해 로그인 과정을 처리하고, 인증에 사용되는 정보를 JWT를 이용해 클라이언트와 소통하기로 결정했다. Spring Security는 기본적으로 Spring의 하위 프레임워크다. 따라서 Spring 기반의 프로젝트에서 호환성이 좋아 쉽게 사용 가능하다. JWT를 사용하는 이유는 쿠키 - 세션이 지닌 문제점 때문이다. 쿠키는 보안에 지나치게 취약하고, 세션은 서버에 부하가 많이 걸린다. 관련해서 쉽게 설명해준 영상이 있으니 보고 오면 좋다... 2023. 12. 6.
Spring Security의 인증 처리 흐름 Spring Security를 구현하고 사용하는데, 어떻게 인증이 진행되는지 모르고 코드만 따라치는 건 아무 의미가 없다. 어떻게 로그인이 되는지 정도는 간단하게 알고 가는 것이 기왕 공부하는 의미가 있지 않을까? 일반적인 클라이언트 - 서버 간 소통은 클라이언트가 뭔가 요청을 쏴주면 서버에서 해당 요청을 받고 이에 맞는 적절한 작업을 통해 응답하는 과정이다. 그런데 인증 / 인가가 추가되면 어떨까? 서버는 클라이언트의 모든 요청을 그냥 받고 수행해서 결과물을 반납할까? 그럼 인증 / 인가의 의미가 없지 않을까? 그럼, 나한테 요청을 보낸 사용자를 인증하는 과정은 어디서 일어나야할까? 해당 과정은 서버가 요청을 받아들이고 일련의 업무를 수행하기 전에 처리되어야 한다. 그러니까 클라이언트 - 서버의 일대일.. 2023. 12. 6.
반응형

티스토리툴바