아장아장거리면서 주책부리는 블로그

http.exceptionHandling() .authenticationEntryPoint(jwtAuthenticationEntryPoint) .accessDeniedHandler(jwtAccessDenialHandler) .and() .authorizeRequests() .antMatchers("/api/auth/sign_in", "/api/auth/join").permitAll() .antMatchers("/api/auth/reissue").access("hasAuthority('USER') or hasAuthority('MANAGER') or hasAuthority('ADMIN')") .antMatchers("/api/members/**").access("hasAuthority('USER') or ..

일단, 다듬는 이유부터 말하자면, 실제 웹사이트에서 회원 정보 수정을 할 때를 생각해보았을 때, 이게 이상하다고 느꼈기 때문이다. 보통 회원정보를 수정하면, 한 페이지에서 이메일, 닉네임, 비밀번호 수정등을 모두 하는데, 지금 만든 프로젝트에서는 각 정보마다 수정을 따로 해주어야 하기 때문이다. 이걸 동적으로 하면 되겠다는 생각이 들었다. 기존의 코드를 조금 인용해서, @Transactional public void editMember(EditMemberRequestDto editMemberRequestDto, Member member){ if(editMemberRequestDto.getNickname() == null && editMemberRequestDto.getEmail() == null && e..

토큰을 재발행하기 위해서는 어떤 과정이 필요할까를 생각해보았다. 필터체인에서 권한 검증을 받는다(여기서 토큰이 검증되지 않을 경우 예외처리된다) HttpServletRequest에서 토큰을 가져온다. 가져온 토큰을 AuthService.reissue에 집어넣는다. 서비스에서 나오는 TokenResponseDto을 HttpServletResponse에 담아준다. 응답을 준다. 정도로 생각했다. 저번과 마찬가지로, 성공과 실패 경우를 생각해보려고 했다. 하지만, 생각해보니, 이에 대한 문제를 생각하지 않아도 될 것 같은 이유가, 모든 경우에 대한 예외를 Spring Security를 만들 때 적용시켜두었다. 그래서 간단하게, 토큰이 정상적으로 있을 때, 토큰이 없을 때, 토큰이 정상적이지 않을 때를 테스트해..

로그인을 할 때, 입력값과 출력값을 생각해보자. 입력 아이디 비밀번호 출력 Access Token Refresh Token 발생가능한 예외사항 아이디가 존재하지 않을 때 아이디를 입력하지 않았을 때 비밀번호가 일치하지 않을 때 비밀번호를 입력하지 않았을 때 이 정도의 경우들을 생각할 수 있다. 발생가능한 예외사항부터 처리하고, 성공하는 경우들을 만들어보려고 한다. 예외를 크게 두 방식으로 묶어보자면, @Valid로 인해 생기는 예외(Validation 이용) 자체적으로 Service에서 확인했을 때 발생하는 예외 이렇게 두 가지가 있다. 일단, Validation을 위한 에러에서는, @RestControllerAdvice public class ValidationExceptionAdvice { @Exce..

일단, 블로그 포스팅을 잠깐 쉬면서, 코드를 다시 한번 돌아보았다. 좌충우돌 만드는 게시판 수준이라지만, 그래도 나름 '생각' 이라는 것을 해보면서 쓰고있다. + 플레이리스트에 아이묭(aimyon) 노래를 틀면서 하기 시작했는데, 기존에 듣던 재즈보다 힘차게 하는 느낌이다(TMI) 기존에, 회원가입 로직을 위해서 Member -> MemberRepository(+MemberCustomRepository) -> MemberService -> MemberController RefreshToken -> RefreshTokenRepository -> RefreshTokenServie -> RefreshTokenController 로 만들려던 계획을 조금 수정했다. DDD라는 것을 조금 찾아보면서, Member,..

이전에 null값으로 인한 예외가 발생되는 것을 컨트롤러 테스트를 만들어 검증해보았다. 이번엔, 중복 발생시 / 비밀번호가 서로 다를 시 / 이메일이 형식에 맞지 않을 시 를 검증할 것이다. 일단 중복이 발생하기 위해서는, 몇가지 선행되어야 할 내용이 있다. 매 순간 비교하기 위한 데이터 하나와, 기존의 데이터가 있어야 한다. 매 단위테스트마다 db를 초기화시켜 다른 테스트가 영향을 받으면 안된다. 이런 점을 맞추기 위해, 테스트를 실행하는 RegisterRequestDto를 반환하는 로직을 하나 만들었다. private static RegisterRequestDto makeTestRegister() { return RegisterRequestDto.builder() .username("test") .n..

이제 컨트롤러를 좀 만들어보며, 테스트도 해보려고 한다. 일단 제일 간단한 회원가입 로직부터 만들고, 테스트를 해봐야겠다. @RestController @RequiredArgsConstructor public class MemberController { private final MemberService memberService; @PostMapping("/join") public String register(@RequestBody @Valid RegisterRequestDto registerRequestDto){ memberService.registerNewMember(registerRequestDto); return "success register"; } } 간단하게 만들었다. 일단, RegisterR..

제목에서 보는 그대로의 목표를 위해 테스트코드로 검증을 해보려고 한다. 일단, and를 이용했을 경우, 검색하는 값이 testUser1을 목표로 하는 파라미터와, testUser2를 목표로 하는 파라미터라면, 검색시에 아무것도 나오지 않는다. 하지만, or과 contains를 입력하면 SearchMemberDto에 username = "11", nickname = null, email = "22"로 검색하면 11, 22번의 두 멤버가 나와야 한다. 이게 잘 이루어지는지 확인해보고 싶었다. @Test @DisplayName("") public void 서로_다른_객체를_요구하며_검색하기() throws Exception{ //given SearchMemberDto searchMemberDto = new S..

저번의 생각을 토대로, 조금 더 최적화를 해보려고 했다. 일단 처음의 코드를 보자면, private BooleanExpression usernameEq(String username, SearchType searchType){ if(username == null || username.isEmpty() || username.isBlank()) return null; if(searchType.equals(CONTAINS)) return member.username.contains(username); return member.username.eq(username); } private BooleanExpression nicknameEq(String nickname, SearchType searchType){ if..

일단 MemberService를 다시 돌아보았다. validate / domain logic / repository사용을 최대한 분리해 각 메서드를 register에서 7줄 정도를 만든게 최대 길이일 정도로 최대한 잘게 나누어 사용해보았다. 이렇게 되면서, 메서드 재사용성을 확인하고, 각 로직에서 에러가 발생했을 때, 어떤 이유인지 확인하기 용이했던 장점이 있다. 또한, 로그인 로직에서 Token까지 MemberService로 묶었을 때 하나의 서비스까지 두개의 도메인을 따로 가져와 다 사용한다는게 조심스러웠는데, 이 부분을 나누는데 시간을 많이 쓴 것 같다. 원래 도메인 로직밖에 테스트할 줄 몰랐는데, 이번에 리포지토리, 서비스 테스트에 대해서 연습해보고 적용해볼 수 있어 더 좋았다. 개인적으로 컨트롤..