[Chanyeol] Week9 미션

[coconutcococode]

🔗 연관 이슈

#100

🛠 작업 내용

JWT 토큰 구현 - 회원가입, 로그인 구현하고 마이페이지도 워크북과 같은 형식으로 개선

OAuth 관련 구현 - 카카오 OAuth 구현

🤖 AI 활용

• AI 사용 안 함
• 코드 작성 아이디어 참고
• 테스트/리팩토링 보조
• 문서/주석 작성 보조
• 기타 (아래에 간단히 작성)

💬 나의 프롬프트

• api/v1/users/{userId} 뿐만 아니라 api/v1/users/me 도 필요한가?
• 현재 내가 수정한 파일들 중에서 좀 더 개선 가능한 점들 있으면 알려줘.

🧠 AI 응답

• 토큰 기반 인증을 실제 API 사용 방식에 맞추기 위해서는 필요합니다. 토큰 기반으로 가면 “요청한 사람이 누구인가”는 토큰에서 알 수 있습니다. 그래서 학습 관점에서는 userId를 URL이나 request param으로 받는 API를 점검하는 게 좋습니다.예를 들어 마이페이지는 현재 /api/v1/users/{userId} 형태인데, 토큰 기반에서는 /api/v1/users/me처럼 만들고 내부에서 SecurityUtil.getCurrentMemberId()를 쓰는 편이 인증/인가 개념을 이해하기 좋습니다.공부할 개념은 인증(Authentication)과 인가(Authorization)의 차이입니다. “로그인한 사람인가?”와 “이 데이터를 볼 권한이 있는 사람인가?”는 다른 문제입니다. 기존 /api/v1/users/{userId}는 남겨두고, 새로 /api/v1/users/me를 추가해서 토큰에서 현재 회원 ID를 꺼내 조회하도록 만들겠습니다. 기존 /api/v1/users/{userId}는 그대로 남겨뒀습니다. 학습용으로 비교하면 {userId} 방식은 클라이언트가 조회 대상을 직접 지정하는 방식이고, /me는 토큰 기반 인증에서 “현재 로그인한 나”를 서버가 판단하는 방식입니다.
• 이후에 다른 플랫폼의 OAuth 구현을 위해 OAuthDTO 인터페이스 작성, 기존 파일들, OAuth 파일들 역할별 분리 등 흐름 점검

✅ 내가 최종 선택한 방법 (이유)

• 한 눈에 보면서 공부하기 편하게 기존 /api/v1/users/{userId}는 남겨두고, 새로 /api/v1/users/me를 추가하여 비교
• 수정된 코드 확인 후 승인

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: dc566d1435

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

JWT 필터에서 하위 예외를 401로 덮어쓰지 마세요

filterChain.doFilter를 try-catch(Exception)로 감싸서 처리하면, JWT 검증과 무관한 컨트롤러/서비스 예외까지 모두 UNAUTHORIZED(401)로 바뀝니다. 이렇게 되면 원래의 비즈니스 에러 코드와 전역 예외 처리 흐름이 깨져 디버깅과 API 계약 학습이 어려워집니다. JWT 파싱/인증 단계에서 발생한 예외만 별도로 처리하고, 그 외 예외는 다시 던져서 @RestControllerAdvice가 처리하도록 분리해 주세요. 다음으로는 서블릿 필터 예외 전파와 Spring Security 예외 처리 체인(ExceptionTranslationFilter) 을 함께 학습하는 것을 권장합니다.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

OAuth 식별자 누락을 문자열 "null"로 저장하지 마세요

소셜 응답에 id가 없을 때 String.valueOf(oAuthMember.getAttribute("id"))는 예외가 아니라 문자열 "null"을 반환하므로, 잘못된 계정이 생성되거나 여러 사용자가 같은 socialUid로 매칭될 수 있습니다. 소셜 로그인에서 socialUid는 계정 식별의 핵심이므로, 값이 비어 있거나 null이면 즉시 예외를 던지도록 검증 로직을 분리해 주세요. 다음으로는 OAuth 사용자 식별자 검증(필수 claim 검증)과 계정 매핑 규칙 을 학습하면 좋습니다.

Useful? React with 👍 / 👎.

[kjhh2605]

[키워드 조사]
세션과 토큰, Access Token과 Refresh Token, OAuth 1.0/2.0의 차이를 장단점 중심으로 정리한 점이 좋습니다. 특히 토큰 탈취, Refresh Token 관리, Scale-out 관점까지 함께 적어 인증 방식 선택 기준을 이해하려는 흐름이 보입니다. 다만 OAuth 2.0은 인증 자체보다 인가 프레임워크라는 관점, Authorization Code 흐름의 참여자 역할, 현재 코드에서 Refresh Token을 아직 발급하지 않는 범위를 함께 표시하면 정리의 정확성이 더 높아집니다.

[코드 리뷰]
세션 기반 로그인 핸들러를 제거하고 JWT 필터, OAuth2 사용자 서비스, 성공 핸들러, /me API를 연결한 방향은 Week9 학습 목표와 잘 맞습니다. Controller에서 @AuthenticationPrincipal로 현재 사용자를 받도록 바꾼 점도 이전의 static SecurityUtil 의존을 줄이는 좋은 개선입니다. 다음 단계에서는 JWT에 담는 권한 claim과 UserDetails 권한 모델을 일치시키고, OAuth 가입/연동 정책을 명확히 분리하며, 토큰 기반 인증 흐름에서 실제 DB 조회 여부와 stateless 개념을 코드 기준으로 설명할 필요가 있습니다.

[kjhh2605]

JWT는 서명 검증만으로 토큰 자체의 무결성과 만료 여부를 확인할 수 있지만, 현재 구현처럼 JwtAuthFilter에서 이메일로 CustomUserDetailsService를 다시 호출하면 매 요청마다 DB 조회가 발생할 수 있습니다. 학습 정리에는 "JWT 방식은 서버 세션 저장소가 필요하지 않지만, 구현에 따라 사용자 상태 확인을 위해 DB 조회를 병행할 수 있습니다"처럼 구분해 두는 것을 권장합니다.

[kjhh2605]

AuthMember#getAuthorities()가 현재 빈 리스트를 반환하므로 role claim도 빈 문자열로 발급됩니다. 이후 hasRole, hasAuthority 같은 인가 규칙을 사용할 계획이라면 Member의 역할 값을 GrantedAuthority로 변환하는 위치를 정하고, JWT claim과 SecurityContext의 권한이 같은 기준을 사용하도록 맞추는 것을 권장합니다.

[kjhh2605]

소셜 고유 ID로 먼저 찾고 이메일로도 찾는 흐름은 기존 계정과 소셜 계정을 연결하려는 의도가 보입니다. 다만 이메일로 찾은 기존 회원에 socialType/socialUid를 저장하지 않으면 계정 연동 정책이 코드에 명확히 남지 않습니다. 일반 회원과 소셜 회원을 자동 연결할지, 별도 동의 후 연결할지 정책을 정하고 Service에서 그 책임을 분리하는 것을 권장합니다.

[kjhh2605]

인증된 사용자 ID를 @AuthenticationPrincipal로 가져온 점은 적절합니다. 다만 userMissionId가 임시 상수로 남아 있으면 요청한 store/mission과 실제 리뷰 작성 대상의 관계가 Service 계층에서 검증되지 않습니다. 리뷰 생성 API의 입력 DTO나 경로에서 사용자 미션 식별자를 명확히 받고, 해당 미션이 현재 회원의 미션인지 검증하는 흐름으로 옮기는 것을 권장합니다.