6주차 과제 - 로그인 구현하기 #70
Conversation
|
한주간 잘 부탁드립니다! |
| if(token == null || token.isBlank()){ | ||
| throw new InvalidTokenException(token); | ||
| } |
There was a problem hiding this comment.
어쩌면 XXX.isBlank(token) 이런 함수로 대체할 수 있을 것 같아요!
객체의 메소드를 호출하는 것과 비교해서 위 코드의 장점은 null 체크를 숨기고 무엇을 하는지만 코드에 보이도록 할 수 있다는 거에요!
| .compact(); | ||
| } | ||
|
|
||
| public Claims decode(String token) { |
| public class AuthenticationService { | ||
|
|
||
| private final JwtUtil jwtUtil; | ||
|
|
||
| public AuthenticationService(JwtUtil jwtUtil) { | ||
| this.jwtUtil = jwtUtil; | ||
| } | ||
|
|
||
| public String login(){ | ||
| return jwtUtil.encode(1L); | ||
| } | ||
|
|
||
| public Claims parseToken(String token) { | ||
| return jwtUtil.decode(token); | ||
| } | ||
| } |
There was a problem hiding this comment.
JwtUtil 을 직접 사용하는 것과 비교해서 AuthenticationService 를 쓰는 것은 어떠한 장점이 있을까요?!!
There was a problem hiding this comment.
인증과 JWT 기능에 대한 관심사가 분리되어 있기 때문에 Service가 인증에 대한 책임을 잘 맡으면 다른 도메인 컨트롤러에서도 유용하게 사용할 수 있을 것 같습니다 ㅎㅎ
There was a problem hiding this comment.
좋아요! 하지만 그렇다면! Claims 를 리턴하면 JWT를 명시하게 되는 것이 될거에요!
There was a problem hiding this comment.
넵 컨트롤러는 AuthenticationService.tokenValidation(String token)을 호출하게만 했고 서비스는 JWT의 존재는 모르게 userId만 받아서 사용자를 찾게만 해봤습니다.
말씀대로 Claims는 JwtUtil에서만 사용하도록 했습니다.
| if(!StringUtils.hasText(token)){ | ||
| throw new InvalidTokenException(token); | ||
| } |
There was a problem hiding this comment.
너무 좋아요! 조금 아쉬운 것은 문자를 가진 것의 반대 보다는 문자가 비어있는 경우 를 테스트하는 것이 좀 더 직관적일 것 같아요!
찾아보니 로그를 직접 유틸클래스를 만들어 볼 수도 있어요!
StringUtils.isEmpty 혹은 Strings.isBlank | Strings.isEmpty 이런식으로 치면 여러가지 함수가 있을 것입니다! 이것들을 참고해보세요!
사용자는 존재하지만 비밀번호가 틀리다면 WrongPasswordException Product 생성 시 사용자 확인 후 생성 , 테스트 코드 추가
| @NotBlank | ||
| @Size(min = 4, max = 1024) |
There was a problem hiding this comment.
한번 경험삼아 메시지를 커스텀 해보는 것은 어떨까요?!
메시지를 커스텀하는 행위는 아주 일반적이니까요!
아니면 나아가서 커스텀 Validator를 만들어보는 겁니다!
There was a problem hiding this comment.
{
"message": null,
"status": "BAD_REQUEST",
"errors": [
"[password] 크기가 4에서 1024 사이여야 합니다",
"[email] 크기가 3에서 2147483647 사이여야 합니다"
]
}일단 검증 실패 시 검증 정보를 위와 같이 반환하게 수정해봤습니다 042eaaa
커스텀 Validator는 내일 진행해보겠습니다!
There was a problem hiding this comment.
@Size(min = 4, max = 1024, message = "")
각 유효성검증마다 메시지를 바꿀 수 있는 것이 좋지 않을까요!
또 메시지는 코드가 아닌 외부 파일로 분리하는 것도 좋은 생각일 것 같아요!
| registerUser = userRepository.save((User.builder() | ||
| .name(name) | ||
| .email(email)) | ||
| .password(password) | ||
| .build()); |
There was a problem hiding this comment.
메소드 안에서만 쓰이는 변수라면 메소드 안으로 스코프를 줄이는 것이 좋을 것 같아요! 이렇게 하면 final 도 붙일 수 있을 것 같아요!
|
|
| * @return Claims JWT의 페이로드 부분을 반환 | ||
| */ | ||
| public Claims decode(String token) { | ||
| if(StringUtils.isEmpty(token) || token.isBlank()){ |
There was a problem hiding this comment.
Strings.isBlank 이면 하나만으로 predicate이 하나로 해결될 것 같아요!
직접 적용은 못 해봤지만 |
|
아 맞습니다!
인터페이스로 만드는 겸!
이번에는 각 인터페이스마다 하나의 기능만을 가지도록 하는 것은 어떨까요?
조회 분리로 나누는 것보다 더 작게 나눠보는 거에요!
|
| User user = mapper.map(loginData , User.class); | ||
| User findUser = userService.findByEmail(user.getEmail()); |
There was a problem hiding this comment.
| User user = mapper.map(loginData , User.class); | |
| User findUser = userService.findByEmail(user.getEmail()); | |
| User findUser = userService.findByEmail(emailFrom(loginData)); |
이런식으로 메소드를 추출해본다면 어떨까요? 구현을 감추면 좀 더 가독성이 좋을 것 같아요!
맞다면 서비스가 복잡해질수록 구현해야하는 인터페이스는 많아지고 타입을 일일이 지정해줘야하는데 이점이 무엇일지 모르겠습니다 ㅎㅎ |
…cationService.java Co-authored-by: 남영환 <ssisksl77@gmail.com>
함수형 인터페이스는 맞습니다. 제가 생각한 것보다 더욱더 범용적인 인터페이스를 만들어주셨군요! 만약 User를 생성하는 인터페이스를 만든다면, |
|
한주간 회고를 작성하고 링크를 올려주세요! |
한 주간 감사했습니다 ㅎㅎ 수고하셨습니다! |
로그인이 필요없는 API
/session/users/users/{id}/users/{id}/products/products/{id}로그인이 필요한 API
/products/products/{id}/products/{id}한 주간 잘 부탁드립니다 ~