feat: 예외 로직 분리#347
Conversation
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! 이 PR은 Apple 로그인 과정에서 발생할 수 있는 이메일 클레임 누락 문제를 해결하기 위해 예외 처리 로직을 개선합니다. 기존 사용자의 재로그인 시나리오와 신규 사용자의 로그인 시나리오를 명확히 구분하여 처리함으로써, Apple 로그인 안정성을 높이고 잠재적인 문제를 더 효과적으로 진단할 수 있도록 합니다. Highlights
🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Changelog
Activity
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. 클레임 없는 이메일, 새로운 길을 찾아서, 로그인 성공. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
안녕하세요. Apple 로그인 예외 처리 로직 분리 작업에 대한 리뷰입니다. 재로그인 시나리오를 식별하기 위한 로직 분리는 좋은 시도이지만, 현재 구현은 재로그인하는 사용자의 로그인을 막는 심각한 버그를 포함하고 있습니다. 재로그인 시에는 예외를 발생시키는 대신, 데이터베이스에서 사용자 정보를 조회하여 로그인을 완료시켜야 합니다. 이에 대한 수정 제안을 코드와 함께 남겼습니다. 또한, 코드에 추가된 주석이 리포지토리 스타일 가이드를 따르도록 수정이 필요해 보입니다. 자세한 내용은 각 리뷰 코멘트를 확인해주세요.
| if (emailObj == null) { | ||
| throw new BaseException(NOT_FOUND_EMAIL); | ||
| boolean existsUser = userRepository.findByProviderId(providerId).isPresent(); | ||
|
|
||
| if (existsUser) { | ||
| // 가설 맞음: 기존 유저 재로그인 케이스 | ||
| log.info("[Apple Login] email claim 없음 & DB 유저 있음. 재로그인 케이스로 확인. providerId={}", providerId); | ||
| throw new BaseException(NOT_FOUND_EMAIL); | ||
| } else { | ||
| // 다른 원인: 신규 유저인데 email 없음 → 슬랙 알럿용 별도 에러코드 | ||
| log.warn("[Apple Login] email claim 없음 & DB 유저 없음. 원인 불명. providerId={}", providerId); | ||
| throw new BaseException(NOT_FOUND_APPLE_EMAIL_NEW_USER); | ||
| } | ||
| } |
There was a problem hiding this comment.
재로그인 시나리오에서 예외를 발생시키면 사용자가 다시 로그인할 수 없게 됩니다. Apple 정책에 따라 재로그인 시에는 이메일 클레임이 제공되지 않으므로, providerId를 사용하여 데이터베이스에서 기존 사용자를 조회해야 합니다.
사용자가 존재할 경우, 해당 사용자의 이메일 정보를 사용하여 OAuthInfo 객체를 생성하고 반환하여 로그인이 정상적으로 완료되도록 해야 합니다. 현재 구현은 재로그인 흐름을 중단시켜 버그를 유발할 수 있습니다.
또한, userRepository.findByProviderId(providerId) 호출이 불필요하게 두 번 발생할 수 있는 구조입니다. Optional<User>를 변수로 받아 처리하는 것이 더 효율적입니다.
아래와 같이 수정하는 것을 제안합니다. 이 제안을 적용하려면 ssu.eatssu.domain.user.entity.User와 java.util.Optional 클래스를 임포트해야 할 수 있습니다.
| if (emailObj == null) { | |
| throw new BaseException(NOT_FOUND_EMAIL); | |
| boolean existsUser = userRepository.findByProviderId(providerId).isPresent(); | |
| if (existsUser) { | |
| // 가설 맞음: 기존 유저 재로그인 케이스 | |
| log.info("[Apple Login] email claim 없음 & DB 유저 있음. 재로그인 케이스로 확인. providerId={}", providerId); | |
| throw new BaseException(NOT_FOUND_EMAIL); | |
| } else { | |
| // 다른 원인: 신규 유저인데 email 없음 → 슬랙 알럿용 별도 에러코드 | |
| log.warn("[Apple Login] email claim 없음 & DB 유저 없음. 원인 불명. providerId={}", providerId); | |
| throw new BaseException(NOT_FOUND_APPLE_EMAIL_NEW_USER); | |
| } | |
| } | |
| if (emailObj == null) { | |
| java.util.Optional<ssu.eatssu.domain.user.entity.User> userOptional = userRepository.findByProviderId(providerId); | |
| if (userOptional.isPresent()) { | |
| // 가설 맞음: 기존 유저 재로그인 케이스 | |
| log.info("[Apple Login] email claim 없음 & DB 유저 있음. 재로그인 케이스로 확인. providerId={}", providerId); | |
| ssu.eatssu.domain.user.entity.User existingUser = userOptional.get(); | |
| return new OAuthInfo(existingUser.getEmail(), providerId); | |
| } else { | |
| // 다른 원인: 신규 유저인데 email 없음 → 슬랙 알럿용 별도 에러코드 | |
| log.warn("[Apple Login] email claim 없음 & DB 유저 없음. 원인 불명. providerId={}", providerId); | |
| throw new BaseException(NOT_FOUND_APPLE_EMAIL_NEW_USER); | |
| } | |
| } |
| boolean existsUser = userRepository.findByProviderId(providerId).isPresent(); | ||
|
|
||
| if (existsUser) { | ||
| // 가설 맞음: 기존 유저 재로그인 케이스 |
There was a problem hiding this comment.
리포지토리 스타일 가이드 8번 규칙에 따르면, 주석에는 작성자 이름과 날짜가 포함되어야 합니다. 규칙에 맞게 수정해 주세요. 예: // [작성자, YYYY-MM-DD] 가설 맞음: 기존 유저 재로그인 케이스
References
- 리포지토리 스타일 가이드 8번 규칙: '각 주석에는 작성자의 이름과 날짜가 포함되어야 합니다.' 현재 주석은 이 형식을 따르지 않고 있습니다. (link)
| log.info("[Apple Login] email claim 없음 & DB 유저 있음. 재로그인 케이스로 확인. providerId={}", providerId); | ||
| throw new BaseException(NOT_FOUND_EMAIL); | ||
| } else { | ||
| // 다른 원인: 신규 유저인데 email 없음 → 슬랙 알럿용 별도 에러코드 |
There was a problem hiding this comment.
리포지토리 스타일 가이드 8번 규칙에 따르면, 주석에는 작성자 이름과 날짜가 포함되어야 합니다. 규칙에 맞게 수정해 주세요. 예: // [작성자, YYYY-MM-DD] 다른 원인: 신규 유저인데 email 없음 → 슬랙 알럿용 별도 에러코드
References
- 리포지토리 스타일 가이드 8번 규칙: '각 주석에는 작성자의 이름과 날짜가 포함되어야 합니다.' 현재 주석은 이 형식을 따르지 않고 있습니다. (link)
2 participants
#️⃣ 346
📝 요약(Summary)
애플 로그인 이슈를 해결하기 위해서 정리했던 가정이 맞는지 확인하기 위해 로그인 예외 처리 분기
💬 공유사항 to 리뷰어
✅ PR Checklist
PR이 다음 요구 사항을 충족하는지 확인하세요.