Conversation
SNS의 핵심 기능인 회원 시스템을 추가합니다.
이제 모든 게시글과 댓글에 작성자 정보가 포함되며, '좋아요'와 회원 프로필 조회가 가능합니다.
Member (회원가입, 닉네임 검색) 기능 추가
PostLike ('좋아요' 토글) 기능 추가
회원 프로필 (작성 글/댓글/좋아요 목록) 조회 API 추가
기존 Post, Comment에 작성자 연동 및 권한 확인 로직 추가
sinsehwan
left a comment
sinsehwan
left a comment
There was a problem hiding this comment.
고생하셨습니다! 로그인 인증/인가까지 다 구현해주셨네요! 좋습니다. Spring Security가 기능을 많이 제공하지만 이에 따라 파급효과를 파악하기 어렵다는 단점도 있습니다. 작동 원리를 나중에 한 번 정리해보시면 많은 도움이 될 것 같습니다. 그동안 과제하시느라 수고하셨습니다!
| @Configuration | ||
| @EnableWebSecurity | ||
| @RequiredArgsConstructor | ||
| public class SecurityConfig { |
There was a problem hiding this comment.
Spring Security를 사용하셨네요! 모듈이 복잡한 편이라서 나중에 인증/인가 전체 흐름 관련해서 파트별로 기능을 정리해두면 좋을 것 같아요~ 해당 부분 템플릿화해두면 초기 프로젝트 진행 시 인증/인가 부분을 빠르게 처리해서 넘겨줄 수 있어서 좋습니다
| @PostMapping("/reissue") | ||
| public ResponseEntity<TokenDto> reissue(@RequestBody TokenRequestDto requestDto) { | ||
| return ResponseEntity.ok(authService.reissue(requestDto)); | ||
| } |
There was a problem hiding this comment.
액세스 토큰 재발급로직까지 구현해 주셨네요! 좋습니다
| @Column(nullable = false) | ||
| private String password; // 실제로는 해싱(Hashing) 필요 | ||
|
|
||
| private String password; |
There was a problem hiding this comment.
이건 코드 리뷰 사항은 아니긴 한데 해싱과 암호화의 차이에 대해서도 알아두시면 좋을 것 같습니다!
해싱 - 단방향
암호화 - 양방향 (암호화 - 복호화)
비밀번호 저장 시 암호화는 키 값 노출 시 복호화가 가능한데, 복호화가 불가능한 해싱 기법을 사용하면 해싱에는 복호화 키 개념이 없기에 상대적으로 안전해서 보통 해싱을 사용하는 것 같아요
| @Getter | ||
| @AllArgsConstructor | ||
| @NoArgsConstructor | ||
| public class MemberLoginRequestDto { | ||
| private String username; | ||
| private String password; |
There was a problem hiding this comment.
DTO의 경우는 Record를 사용하시는 걸 추천드립니다! 그러면 @Getter, @AllArgsConstructor를 사용하지 않아도 되기에 Lombok에 의존하지 않고도 깔끔하게 개발할 수 있습니다. 그리고 불변 객체라 동시에 여러 쓰레드를 사용하더라도 안전하다는 장점이 있습니다.
| public class MemberResponseDto { | ||
| private Long id; | ||
| private String username; | ||
| private String nickname; |
There was a problem hiding this comment.
username도 담아주는 게 활용하기 좋겠네요! 그런데 id의 경우 나중에 프론트와 협업할 때는 응답에 필요한 경우가 종종 생깁니다. 예를 들어 목록 조회 -> 상세 페이지 흐름에서 상세 페이지 요청을 위해 대상 memberId를 프론트 단에서 알아야 하는 상황 등이 있겠네요. 비즈니스 로직 흐름 고려하셔서 진행하시면 될 것 같습니다
| import org.springframework.security.crypto.password.PasswordEncoder; | ||
|
|
||
| @Getter | ||
| @Setter |
There was a problem hiding this comment.
DTO의 경우 말 그대로 데이터 전송용 객체다 보니 처음 만들 때 완전하게 만들고 setter를 지양하는 게 좋을 것 같습니다!
| import lombok.Builder; | ||
| import lombok.Data; | ||
|
|
||
| @Data |
There was a problem hiding this comment.
@Data의 경우 기능이 너무 많아서 객체의 책임 관점에서 조금 위험할 수도 있을 것 같아요!
| if (memberRepository.existsByUsername(requestDto.getUsername())) { | ||
| throw new RuntimeException("이미 가입되어 있는 유저입니다"); | ||
| } |
There was a problem hiding this comment.
이 경우 조회 로직 최적화를 위해 username에 인덱스를 거는 방안을 고려해도 되겠네요!
| public TokenDto reissue(TokenRequestDto tokenRequestDto) { | ||
| // 1. Refresh Token 검증 | ||
| if (!jwtTokenProvider.validateToken(tokenRequestDto.getRefreshToken())) { | ||
| throw new RuntimeException("Refresh Token 이 유효하지 않습니다."); |
There was a problem hiding this comment.
RuntimeException보다는 더 상세한 인증 관련 예외나 커스텀 예외를 만들어서 전역 예외 처리기에서 인증 예외만 따로 처리할 수 있으면 더 좋을 것 같습니다!
2 participants
변경점 👍
Feat: 회원가입 + 로그인 구현 [JWT 기반 구현] + RefreshToken
스크린샷 🖼