😐문제 정의 테스트 시 사용자 인증 정보를 세팅해야 하는데 저는 JWT를 통해 인증을 구현했기 때문에 매번 로그인 요청을 시도하고 이 때 얻은 토큰을 담아서 요청을 다시 보내야 하는 문제점이 있었습니다. 저는 Spring Security에서 지원하는 @WithUserDetails를 이용해 인증 정보를 세팅하기로 했으나 @BeforeEach를 이용해 DB에 데이터를 저장한 뒤 인증 세팅을 하는 과정에서도 NPE가 뜨는 문제가 발생했습니다... 😐@WithUserDetails와 @WithMockUser 동작원리 및 차이 사용하기에 앞서 둘의 차이를 알고 써야겠다 싶어 동작 원리를 공부해봤습니다. 요약 둘 모두 테스트에 사용하기 위한 가짜 인증 객체를 설정하기 위해 사용됩니다. (원래대로라면 토큰을 이용해서 ..
전체 글
😐정리 - Websocket Handshake요청은 일반적인 HTTP요청을 잡는 HandlerInterceptor에 걸리지 않아 별도의 처리가 필요하다. - STOMP CLIENT에서 담는 헤더들은 웹소켓 연결 이후 STOMP 연결이 진행될 때부터 사용이 가능하다. 즉, Handshake Interceptor에서 토큰을 받아 인증을 진행할 수가 없음 - ChannelInterceptor 이용하자 -> COMMAND가 CONNECT일 때만 인증 여부 검증하도록 구현 - 위 방법은 인증을 여러번 진행하지는 않지만 메시지 전송시에도 토큰을 달고 다녀야 해서 전송 비용이 증가함 - 최종 해결책은 토큰을 쿠키로 관리하여 웹소켓 연결 시 동작하는 Handshake Interceptor에서 한번만 검사하도록 한다. ..
정리 오랜만에 테스트를 짜던 중 회원가입 부분에서 계속 비밀번호 매칭이 안되는 버그를 발견했습니다.. 결론부터 말하자면 비밀번호 비교는 passwordEncoder.matches(비밀번호, 암호화된 비밀번호) 를 이용해야합니다. Security내부 로직을 뜯어봤을 때 위처럼 비교하는 코드를 봤기 때문에 알고는 있었지만 그런가 보다 하고 지나쳤었던 로직인데 다 이유가 있던거였.... 테스트 과정 및 실패의 이유 분석 단순하게 생각해서 passwordEncoder로 암호화 시킨 비밀번호를 DB에 저장시킨것이기 때문에 똑같은 비밀번호를 암호화 시켜서 비교한다면 성공할거라고 생각했습니다. 아래처럼요..(member는 테스트 결과 값으로 다시 조회한 객체입니다.) Assertions.assertThat(membe..