[WTH-237] 애플 로그인 수정 및 로그인 시 유저 정보 반환#44
Conversation
📝 WalkthroughWalkthroughApple 소셜 로그인 콜백 처리 기능이 추가되었습니다. Apple ID 토큰을 직접 인증하는 포트/어댑터 확장, 콜백 컨트롤러, 이름 파싱, DTO에 사용자 이름 필드 추가 및 관련 매퍼·유스케이스 변경이 포함됩니다. Changes
Sequence Diagram(s)sequenceDiagram
participant Client as Apple Sign In Client
participant Controller as SocialCallbackController
participant UseCase as SocialLoginUseCase
participant AuthPort as SocialAuthPort
participant Adapter as AppleSocialAuthAdapter
participant Mapper as UserMapper
participant CookieProv as TokenCookieProvider
Client->>Controller: POST /api/v4/users/social/apple/callback (id_token, user)
alt error or missing id_token
Controller->>Client: 302 Redirect (error)
else valid id_token
Controller->>Controller: parse userJson -> userName?
Controller->>UseCase: socialLoginByAppleCallback(idToken, userJson)
UseCase->>AuthPort: authenticateWithIdToken(idToken)
AuthPort->>Adapter: authenticateWithIdToken(idToken)
Adapter->>Adapter: decode id_token, build SocialAuthResult
Adapter-->>UseCase: SocialAuthResult
UseCase->>UseCase: override name if parsed non-blank
UseCase->>UseCase: processLogin(authResult) -> JwtDto, isRegistered
UseCase->>Mapper: toSocialLoginResponse(user.name, token, isRegistered)
Mapper-->>UseCase: SocialLoginResponse
UseCase-->>Controller: SocialLoginResponse
Controller->>CookieProv: create access/refresh cookies
Controller-->>Client: 302 Redirect (registered, name) + Set-Cookie
end
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Suggested labels
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (3)
src/main/kotlin/com/weeth/global/config/SecurityConfig.kt (1)
91-91: CORS 설정 확인이 필요합니다.Apple의
form_post방식은 서버 리다이렉트(302)가 아닌 폼 POST로 브라우저가 직접 요청을 보내므로, CORS preflight가 발생하지 않습니다. 이 CORS 항목이 실제로 필요한지 확인해 주세요. 불필요하더라도 해가 되지는 않지만, 불필요한 설정은 제거하는 것이 좋습니다.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/main/kotlin/com/weeth/global/config/SecurityConfig.kt` at line 91, Review the CORS origin entry "https://appleid.apple.com" in SecurityConfig and confirm whether the application actually needs it for cross-origin requests (Apple's form_post uses direct browser POSTs without CORS preflight); if it's unnecessary remove it from the allowed origins list (e.g., the origins collection used in the CORS configuration/bean such as the corsConfiguration or allowedOrigins variable in SecurityConfig) otherwise leave it but add a comment explaining why it's required for clarity. Ensure you update any related tests or documentation that reference the CORS origins.src/main/kotlin/com/weeth/domain/user/application/usecase/command/SocialLoginUseCase.kt (1)
42-45: TODO 주석: Apple 계정 연결 해제 구현 필요.탈퇴 기능 구현 시 Apple Revoke Tokens API를 호출하기 위해 refresh token 저장이 필요하다는 점이 명시되어 있습니다. 이 작업을 추적하기 위한 이슈를 생성할까요?
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/main/kotlin/com/weeth/domain/user/application/usecase/command/SocialLoginUseCase.kt` around lines 42 - 45, Add a tracked task and implement storing Apple refresh tokens when handling the Apple OAuth callback in SocialLoginUseCase: exchange the callback code at Apple’s token endpoint, persist the returned refresh_token to the user/Auth entity (so it’s available for future revocation), and ensure the revoke flow uses that stored refresh_token when calling the Apple Revoke Tokens API; create an issue to track this work and link it from the TODO in SocialLoginUseCase.src/main/kotlin/com/weeth/domain/user/presentation/SocialCallbackController.kt (1)
72-80: 광범위한 Exception catch는 디버깅을 어렵게 할 수 있습니다.콜백 핸들러에서 graceful degradation을 위해 모든 예외를 잡는 것은 합리적이나, 특정 예외 타입(예:
JsonProcessingException,AuthenticationException)을 먼저 처리하고 로그 레벨을 다르게 하면 운영 시 문제 파악이 더 용이합니다.♻️ 선택적 리팩토링 제안
- } catch (e: Exception) { - log.error("Apple 콜백 처리 중 오류 발생", e) + } catch (e: com.fasterxml.jackson.core.JsonProcessingException) { + log.warn("Apple 콜백 JSON 파싱 오류", e) + redirect( + UriComponentsBuilder + .fromUriString(frontendRedirectUri) + .queryParam("error", "invalid_user_data") + .toUriString(), + ) + } catch (e: Exception) { + log.error("Apple 콜백 처리 중 예기치 않은 오류 발생", e)🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/main/kotlin/com/weeth/domain/user/presentation/SocialCallbackController.kt` around lines 72 - 80, In SocialCallbackController's Apple callback handler, replace the broad catch(Exception e) with targeted catches for likely issues first (e.g., catch com.fasterxml.jackson.core.JsonProcessingException and org.springframework.security.core.AuthenticationException) to log more specific messages and appropriate log levels, handle each case (return the same redirect with specific error query param like "invalid_payload" or "auth_failed"), and keep a final catch(Exception e) as a fallback that logs the generic error and performs the existing redirect; update log messages to include the exception message/stack as appropriate.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In
`@src/main/kotlin/com/weeth/domain/user/presentation/SocialCallbackController.kt`:
- Around line 55-60: redirectUri 생성 시 response.name에 한글·공백 등 특수문자가 포함될 경우 제대로
인코딩되지 않으므로 UriComponentsBuilder를 통해 쿼리 파라미터를 설정한 뒤 build()와 encode()를 호출해 모든
특수문자를 인코딩한 후 toUriString()으로 변환하도록 변경하세요; 즉 현재
UriComponentsBuilder.fromUriString(frontendRedirectUri).queryParam("registered",
response.registered).queryParam("name", response.name).toUriString() 흐름을 build()
-> encode() -> toUriString() 순서로 바꾸어 redirectUri를 생성하도록 수정하면 됩니다 (참조:
UriComponentsBuilder, frontendRedirectUri, response.name, redirectUri).
- Around line 62-71: Apple's form_post callback is dropping cookies due to
SameSite=Lax; update the cookie creation for the Apple callback in
SocialCallbackController to use SameSite=None and Secure. Add a dedicated method
on TokenCookieProvider (e.g., createAppleAccessTokenCookie and
createAppleRefreshTokenCookie or a buildCookie variant with a sameSiteOverride
param) that constructs cookies using CookieProperties or buildCookie with
sameSite="None" and secure=true, then call those methods instead of
createAccessTokenCookie/createRefreshTokenCookie in the Apple callback response
construction so the headers set HttpHeaders.SET_COOKIE include SameSite=None;
Secure.
---
Nitpick comments:
In
`@src/main/kotlin/com/weeth/domain/user/application/usecase/command/SocialLoginUseCase.kt`:
- Around line 42-45: Add a tracked task and implement storing Apple refresh
tokens when handling the Apple OAuth callback in SocialLoginUseCase: exchange
the callback code at Apple’s token endpoint, persist the returned refresh_token
to the user/Auth entity (so it’s available for future revocation), and ensure
the revoke flow uses that stored refresh_token when calling the Apple Revoke
Tokens API; create an issue to track this work and link it from the TODO in
SocialLoginUseCase.
In
`@src/main/kotlin/com/weeth/domain/user/presentation/SocialCallbackController.kt`:
- Around line 72-80: In SocialCallbackController's Apple callback handler,
replace the broad catch(Exception e) with targeted catches for likely issues
first (e.g., catch com.fasterxml.jackson.core.JsonProcessingException and
org.springframework.security.core.AuthenticationException) to log more specific
messages and appropriate log levels, handle each case (return the same redirect
with specific error query param like "invalid_payload" or "auth_failed"), and
keep a final catch(Exception e) as a fallback that logs the generic error and
performs the existing redirect; update log messages to include the exception
message/stack as appropriate.
In `@src/main/kotlin/com/weeth/global/config/SecurityConfig.kt`:
- Line 91: Review the CORS origin entry "https://appleid.apple.com" in
SecurityConfig and confirm whether the application actually needs it for
cross-origin requests (Apple's form_post uses direct browser POSTs without CORS
preflight); if it's unnecessary remove it from the allowed origins list (e.g.,
the origins collection used in the CORS configuration/bean such as the
corsConfiguration or allowedOrigins variable in SecurityConfig) otherwise leave
it but add a comment explaining why it's required for clarity. Ensure you update
any related tests or documentation that reference the CORS origins.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 018f8452-7701-4b01-b25e-d83fc24884bd
📒 Files selected for processing (9)
src/main/kotlin/com/weeth/domain/user/application/dto/response/SocialLoginResponse.ktsrc/main/kotlin/com/weeth/domain/user/application/mapper/UserMapper.ktsrc/main/kotlin/com/weeth/domain/user/application/usecase/command/SocialLoginUseCase.ktsrc/main/kotlin/com/weeth/domain/user/domain/port/SocialAuthPort.ktsrc/main/kotlin/com/weeth/domain/user/infrastructure/AppleSocialAuthAdapter.ktsrc/main/kotlin/com/weeth/domain/user/presentation/SocialCallbackController.ktsrc/main/kotlin/com/weeth/global/config/SecurityConfig.ktsrc/main/kotlin/com/weeth/global/config/properties/OAuthProperties.ktsrc/main/resources/application.yml
src/main/kotlin/com/weeth/domain/user/presentation/SocialCallbackController.kt
Show resolved
Hide resolved
| ResponseEntity | ||
| .status(HttpStatus.FOUND) | ||
| .header(HttpHeaders.LOCATION, redirectUri) | ||
| .header( | ||
| HttpHeaders.SET_COOKIE, | ||
| tokenCookieProvider.createAccessTokenCookie(response.accessToken).toString(), | ||
| ).header( | ||
| HttpHeaders.SET_COOKIE, | ||
| tokenCookieProvider.createRefreshTokenCookie(response.refreshToken).toString(), | ||
| ).build() |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
SameSite cookie behavior on cross-origin POST redirect 302 response
💡 Result:
SameSite cookie behavior on a cross-origin POST request followed by a 302 redirect depends on the SameSite attribute value (Strict, Lax, or None) and whether the subsequent redirect request is classified as "same-site" or "cross-site". Cookies set in the 302 response are always stored by the browser before following the redirect (result 1), but whether existing cookies (including those just set) are sent on the follow-up request depends on SameSite rules. Key concepts from specs (results 9,10,13,14,18): - A request is "cross-site" if the initiator site (top-level browsing context) differs from the request URL's site (scheme+registrable domain). - For redirects: HTTP 302 redirects preserve the initiator context, so a cross-site POST keeps the chain cross-site for follow-up requests (results 3,4,22). Sec-Fetch-Site remains "cross-site". - SameSite=Strict: Cookie sent ONLY on same-site requests, never cross-site (results 3,4,9,13). - SameSite=Lax: Sent on same-site requests + cross-site top-level navigations with "safe" methods (GET, HEAD). Cross-site POST or unsafe methods: not sent. Lax-allowing-unsafe mode (some browsers) sends on cross-site top-level regardless of method, but POST after cross-origin POST redirect typically blocked (results 2,5,6,9). - SameSite=None (requires Secure): Sent on all requests, cross-site included (results 9,11). Scenario example (OAuth/login flow, results 5,6): 1. Cross-origin POST to /login (cross-site, initiator from other site). 2. Server responds 302 Location: /dashboard + Set-Cookie (session). 3. Browser stores cookie, follows with GET /dashboard. - If chain cross-site: Strict=None sent; Lax=not sent (not safe method exception); None=sent. - Common breakage with Strict/Lax leads to workarounds like meta-refresh 200 (changes to same-site navigation, result 6). For cross-origin POST 302 specifically: Cookies with Lax/Strict typically NOT sent on redirect leg if chain cross-site; use None for cross-site compatibility.
Citations:
- 1: https://medium.com/@piyalidas.it/why-cookies-are-set-even-on-302-redirects-85065077b668
- 2: https://stackoverflow.com/questions/66675803/samesite-strict-cookies-are-not-included-in-302-redirects-when-user-clicks-link
- 3: https://stackoverflow.com/questions/75184259/samesite-strict-cookies-and-cross-site-requests-with-redirections
- 4: 302 Redirect Cookie Delay sergiodxa/remix-auth#232
- 5: https://stackoverflow.com/questions/42216700/how-can-i-redirect-after-oauth2-with-samesite-strict-and-still-get-my-cookies
- 6: https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Set-Cookie
- 7: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSite
- 8: https://httpwg.org/http-extensions/draft-ietf-httpbis-incremental-04/draft-ietf-httpbis-rfc6265bis.html
- 9: https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-rfc6265bis-22
- 10: http://fetch.spec.wintercg.org/
🏁 Script executed:
# TokenCookieProvider와 쿠키 설정 관련 파일 찾기
fd -t f "TokenCookieProvider\|CookieProperties" --case-sensitiveRepository: Team-Weeth/weeth-server
Length of output: 49
🏁 Script executed:
# SocialCallbackController 전체 내용 확인
cat -n src/main/kotlin/com/weeth/domain/user/presentation/SocialCallbackController.ktRepository: Team-Weeth/weeth-server
Length of output: 4817
🏁 Script executed:
# cookieProperties 또는 Cookie 관련 설정 파일 찾기
fd -t f -i "cookie" | grep -i "properties\|config"Repository: Team-Weeth/weeth-server
Length of output: 137
🏁 Script executed:
# TokenCookieProvider 파일 찾기
fd -t f "TokenCookieProvider"Repository: Team-Weeth/weeth-server
Length of output: 240
🏁 Script executed:
# CookieProperties 내용 확인
cat -n src/main/kotlin/com/weeth/global/config/properties/CookieProperties.ktRepository: Team-Weeth/weeth-server
Length of output: 850
🏁 Script executed:
# TokenCookieProvider 내용 확인
cat -n src/main/kotlin/com/weeth/global/auth/jwt/application/service/TokenCookieProvider.ktRepository: Team-Weeth/weeth-server
Length of output: 1994
🏁 Script executed:
# Verify if there are any alternative token handling methods or other Apple callback implementations
rg -i "apple|samesite" --type kt -A 3 -B 3 | head -80Repository: Team-Weeth/weeth-server
Length of output: 93
🏁 Script executed:
# Check if there's any frontend token handling via query params or other methods
rg "accessToken|refreshToken" src/main/kotlin/com/weeth/domain/user/presentation/ --type ktRepository: Team-Weeth/weeth-server
Length of output: 93
🏁 Script executed:
# Verify the scenario more directly
rg "apple" -i --max-count=20Repository: Team-Weeth/weeth-server
Length of output: 13812
Apple 콜백의 SameSite 쿠키 이슈로 인해 토큰이 프론트엔드에 전달되지 않습니다.
Apple의 form_post 방식은 appleid.apple.com에서 크로스 오리진 POST 요청을 보내므로, 이 엔드포인트의 302 응답에 포함된 SameSite=Lax 쿠키는 브라우저가 무시합니다. 현재 CookieProperties의 기본값이 sameSite = "Lax"이고, TokenCookieProvider.buildCookie()가 이 값을 사용하기 때문에 액세스/리프레시 토큰 쿠키가 프론트엔드에 전달되지 않아 Apple 로그인이 실패합니다.
해결 방안:
- Apple 콜백 전용으로
SameSite=None; Secure쿠키를 생성하는 별도 메서드 제공 - 또는 토큰을 쿠키 대신 리다이렉트 URL fragment(
#) 또는 localStorage 스크립트로 전달하고 프론트엔드에서 처리
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In
`@src/main/kotlin/com/weeth/domain/user/presentation/SocialCallbackController.kt`
around lines 62 - 71, Apple's form_post callback is dropping cookies due to
SameSite=Lax; update the cookie creation for the Apple callback in
SocialCallbackController to use SameSite=None and Secure. Add a dedicated method
on TokenCookieProvider (e.g., createAppleAccessTokenCookie and
createAppleRefreshTokenCookie or a buildCookie variant with a sameSiteOverride
param) that constructs cookies using CookieProperties or buildCookie with
sameSite="None" and secure=true, then call those methods instead of
createAccessTokenCookie/createRefreshTokenCookie in the Apple callback response
construction so the headers set HttpHeaders.SET_COOKIE include SameSite=None;
Secure.
There was a problem hiding this comment.
백엔드와 프론트 도메인이 맞으면 문제 없지 않아?
There was a problem hiding this comment.
@hyxklee, 맞습니다. 제 분석에 보완이 필요합니다.
Set-Cookie 헤더는 응답에서 쿠키를 저장하는 역할이고, SameSite 속성은 쿠키를 요청에 포함해 전송할 때만 적용됩니다. 즉, Apple에서 크로스 오리진 POST로 들어와도 302 응답의 Set-Cookie는 브라우저에 정상적으로 저장됩니다.
이후 백엔드와 프론트엔드가 동일한 registrable domain(e.g., api.weeth.kr ↔ x.weeth.kr → 둘 다 weeth.kr)을 공유하고, 쿠키의 Domain 속성이 .weeth.kr로 설정되어 있다면, SameSite=Lax 쿠키는 same-site 요청으로 간주되어 정상적으로 전송됩니다.
따라서 두 도메인이 같은 eTLD+1을 공유한다면 제가 지적한 SameSite=Lax 이슈는 해당되지 않습니다. 지적이 맞습니다.
✏️ Learnings added
Learnt from: hyxklee
Repo: Team-Weeth/weeth-server PR: 44
File: src/main/kotlin/com/weeth/domain/user/presentation/SocialCallbackController.kt:62-71
Timestamp: 2026-03-31T06:54:59.595Z
Learning: In the weeth-server project (Kotlin/Spring), the Apple Sign In callback (SocialCallbackController) sets SameSite=Lax cookies in the 302 redirect response. This is acceptable as long as the backend and frontend share the same registrable domain (e.g., both under weeth.kr), because Set-Cookie stores cookies regardless of SameSite, and SameSite=Lax allows same-site requests. The SameSite=None concern would only apply if backend and frontend are on completely different domains.
Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.
soo0711
left a comment
soo0711
left a comment
There was a problem hiding this comment.
수고하셨습니다!! 리뷰 하나 확인부탁드려용
| .header(HttpHeaders.LOCATION, uri) | ||
| .build() | ||
|
|
||
| private fun parseAppleUserName(userJson: String?): String? { |
There was a problem hiding this comment.
컨트롤러는 요청/응답과 흐름 제어를 담당하는데
해당 매서드(파싱, 추출)은 도메인로직에 가까워보입니당
유스케이스로 책임을 이동하는 건 어떨까요?? 아니면 별도의 추출클래스로 만들어도 괜찮을 것 같아욤
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
src/test/kotlin/com/weeth/domain/user/application/usecase/command/SocialLoginUseCaseTest.kt (1)
38-47:⚠️ Potential issue | 🟠 MajorApple callback 핵심 경로 테스트가 빠져 있습니다.
ObjectMapper의존성이 추가됐지만, 현재 케이스는socialLoginByApple중심이라socialLoginByAppleCallback의 이름 파싱(정상 JSON/비정상 JSON/null user) 경로 회귀를 잡기 어렵습니다. 이번 PR 목표(로그인 시 이름 반환)를 직접 검증하는 테스트를 보강해 주세요.테스트 보강 예시
+ describe("socialLoginByAppleCallback") { + it("user JSON에서 이름을 파싱해 반환한다") { + // given + // when + // then: result.name shouldBe "홍길동" + } + + it("user JSON이 없거나 파싱 실패 시 name은 null로 처리된다") { + // given malformed/null user json + // when + // then: result.name shouldBe null + } + }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/test/kotlin/com/weeth/domain/user/application/usecase/command/SocialLoginUseCaseTest.kt` around lines 38 - 47, Add unit tests covering the Apple callback parsing paths for SocialLoginUseCase: specifically exercise the socialLoginByAppleCallback flow using the injected ObjectMapper to simulate (1) valid JSON with a name, (2) invalid/malformed JSON, and (3) JSON that yields a null user; assert that when valid JSON is provided the returned login result includes the user's name (per PR goal), and for invalid or null cases the use case handles errors or nulls as expected. Locate and extend SocialLoginUseCaseTest to mock ObjectMapper.deserialize behavior (or readTree) for those three scenarios, invoke SocialLoginUseCase.socialLoginByAppleCallback (or the method that delegates to it) and verify interactions with userRepository/userSocialAccountRepository and the jwtManageUseCase as appropriate. Ensure tests assert both successful name propagation and proper fallback/error handling.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Outside diff comments:
In
`@src/test/kotlin/com/weeth/domain/user/application/usecase/command/SocialLoginUseCaseTest.kt`:
- Around line 38-47: Add unit tests covering the Apple callback parsing paths
for SocialLoginUseCase: specifically exercise the socialLoginByAppleCallback
flow using the injected ObjectMapper to simulate (1) valid JSON with a name, (2)
invalid/malformed JSON, and (3) JSON that yields a null user; assert that when
valid JSON is provided the returned login result includes the user's name (per
PR goal), and for invalid or null cases the use case handles errors or nulls as
expected. Locate and extend SocialLoginUseCaseTest to mock
ObjectMapper.deserialize behavior (or readTree) for those three scenarios,
invoke SocialLoginUseCase.socialLoginByAppleCallback (or the method that
delegates to it) and verify interactions with
userRepository/userSocialAccountRepository and the jwtManageUseCase as
appropriate. Ensure tests assert both successful name propagation and proper
fallback/error handling.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 27be175f-2a32-4fc2-9adf-326f5ddce34b
📒 Files selected for processing (1)
src/test/kotlin/com/weeth/domain/user/application/usecase/command/SocialLoginUseCaseTest.kt
2 participants
📌 Summary
애플 로그인을 Web Flow에 맞게 수정했습니다
소셜 로그인시 유저 이름을 반환하도록 수정했습니다.
📝 Changes
What
""
Why
애플 로그인이 Web 방식의 경우는 서버 리다이렉트를 하는 방식으로 구현해야 하기 때문
How
카카오 소셜 로그인 응답 dto에 유저 이름 추가
애플 로그인 call back api 추가
📸 Screenshots / Logs
💡 Reviewer 참고사항
✅ Checklist
Summary by CodeRabbit