Conversation
+ 팔로우 등록/취소 카운트 로직 추가
Walkthrough회원탈퇴(soft-delete) 엔드포인트와 서비스 로직을 추가하고, 리프레시 토큰 쿠키 삭제 로직을 공통 헬퍼로 분리했으며, 팔로우 생성/삭제 시 팔로우 카운터를 동기화하고 언팔로우 응답 코드를 201→200으로 변경했습니다. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes
Possibly related PRs
Poem
Pre-merge checks and finishing touches❌ Failed checks (2 warnings)
✅ Passed checks (3 passed)
✨ Finishing touches
🧪 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: 3
🧹 Nitpick comments (2)
src/main/java/team/wego/wegobackend/user/domain/User.java (1)
141-143:updatedeleted메서드 네이밍/시그니처 개선 제안기능 자체는 단순히 soft delete 플래그를 토글하는 것으로 문제 없지만,
- 메서드명은
updatedeleted보다updateDeleted(또는markDeleted,changeDeleted)처럼 camelCase를 맞추는 편이 가독성에 좋습니다.- 컬럼이
nullable = false이므로, 파라미터 타입을Boolean대신boolean으로 두면 null 전달에 의한 런타임 오류 가능성을 줄일 수 있습니다.다른
updateXxx계열 메서드와 함께 정리해 두면 도메인 모델을 이해하기 더 쉬울 것 같습니다.src/main/java/team/wego/wegobackend/auth/presentation/AuthController.java (1)
128-136: Refresh 토큰 쿠키 보안 속성은 적절하나, CSRF 대응 전체 전략 점검 권장
createRefreshTokenCookie/deleteRefreshTokenCookie에서HttpOnly,Secure,SameSite=Strict,Path=/를 모두 설정한 점은 좋습니다. 다만 애플리케이션이 쿠키 기반 인증을 일부라도 사용하고 있다면(특히/refresh), 전체적인 CSRF 방어 전략(Spring Security CSRF 설정, CORS, 프론트엔드 호출 패턴 등)을 한 번 더 점검해 두는 것이 안전합니다.예를 들어:
- 세션/폼 기반 인증을 사용한다면 Spring Security CSRF 토큰 사용 여부,
- 순수 JWT 헤더 기반이라면, 쿠키는 오직 refresh 용도로만 쓰이고 민감한 상태 변경 API에서는 헤더 기반 인증만 사용하는지
정도를 확인해 두면 좋겠습니다.
Also applies to: 141-148
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (6)
src/main/java/team/wego/wegobackend/auth/application/AuthService.java(3 hunks)src/main/java/team/wego/wegobackend/auth/presentation/AuthController.java(5 hunks)src/main/java/team/wego/wegobackend/auth/presentation/AuthControllerDocs.java(3 hunks)src/main/java/team/wego/wegobackend/user/application/FollowService.java(2 hunks)src/main/java/team/wego/wegobackend/user/domain/User.java(1 hunks)src/main/java/team/wego/wegobackend/user/presentation/UserController.java(1 hunks)
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-12-07T11:11:53.287Z
Learnt from: Be-HinD
Repo: WeGo-Together/WeGo_BackEnd PR: 32
File: src/test/http/auth/auth-api.http:25-27
Timestamp: 2025-12-07T11:11:53.287Z
Learning: IntelliJ HTTP client (.http files) automatically manages cookies between requests in the same file. When reviewing .http test files, a refresh token endpoint test does not need an explicit Cookie header because cookies from previous requests (e.g., login) are automatically included by the IDE.
Applied to files:
src/main/java/team/wego/wegobackend/auth/presentation/AuthController.java
🧬 Code graph analysis (1)
src/main/java/team/wego/wegobackend/auth/application/AuthService.java (2)
src/main/java/team/wego/wegobackend/user/exception/UserNotFoundException.java (1)
UserNotFoundException(6-11)src/main/java/team/wego/wegobackend/auth/exception/UserNotFoundException.java (1)
UserNotFoundException(6-11)
🪛 ast-grep (0.40.0)
src/main/java/team/wego/wegobackend/auth/presentation/AuthController.java
[warning] 147-147: The application does not appear to verify inbound requests which can lead to a Cross-site request forgery (CSRF) vulnerability. If the application uses cookie-based authentication, an attacker can trick users into sending authenticated HTTP requests without their knowledge from any arbitrary domain they visit. To prevent this vulnerability start by identifying if the framework or library leveraged has built-in features or offers plugins for CSRF protection. CSRF tokens should be unique and securely random. The Synchronizer Token or Double Submit Cookie patterns with defense-in-depth mechanisms such as the sameSite cookie flag can help prevent CSRF. For more information, see: [Cross-site request forgery prevention](https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Req\ uest_Forgery_Prevention_Cheat_Sheet.html).
Context: response.addCookie(deleteCookie);
Note: [CWE-352] Cross-Site Request Forgery (CSRF). [REFERENCES]
- https://stackoverflow.com/questions/42717210/samesite-cookie-in-java-application
(cookie-missing-samesite-java)
🔇 Additional comments (3)
src/main/java/team/wego/wegobackend/user/application/FollowService.java (1)
47-48: 팔로우/언팔로우 시 카운트 갱신 로직 적절팔로우 생성/삭제 이후에 팔로워·팔로이 카운트를 도메인 메서드로 증감시키는 구조가 자연스럽고, 트랜잭션 안에서 영속 엔티티를 수정하는 방식도 문제 없어 보입니다.
Also applies to: 68-69
src/main/java/team/wego/wegobackend/user/presentation/UserController.java (1)
124-125: 언팔로우 응답 코드 200으로 변경 타당DELETE 요청에 201(Created) 대신 200(OK)을 반환하도록 수정한 부분이 HTTP语義에 더 잘 맞습니다.
ApiResponse내부 코드도 200으로 맞춰 일관성 있습니다.src/main/java/team/wego/wegobackend/auth/presentation/AuthController.java (1)
75-86: Refresh 토큰 쿠키 삭제 로직 공통화는 좋습니다
logout에서 직접 쿠키 속성을 세팅하던 코드를deleteRefreshTokenCookie로 추출하고,SameSite=Strict,HttpOnly,Secure,Path=/,MaxAge=0를 모두 일관되게 설정한 점이 좋습니다. 중복 코드 제거와 함께 쿠키 속성 누락 위험도 줄어들었습니다.Also applies to: 137-149
src/main/java/team/wego/wegobackend/auth/presentation/AuthController.java
Show resolved
Hide resolved
| import jakarta.servlet.http.HttpServletResponse; | ||
| import jakarta.validation.Valid; | ||
| import org.springframework.http.ResponseEntity; | ||
| import org.springframework.security.core.annotation.AuthenticationPrincipal; |
There was a problem hiding this comment.
문서의 회원탈퇴 설명(DB Soft Delete)와 실제 구현 불일치
Docs 인터페이스 시그니처는 AuthController 구현과 잘 맞지만, 설명에는 *"DB Soft Delete + refreshCookie 제거"*라고 되어 있는 반면 현재 AuthController.withDraw는 refresh 쿠키 삭제만 수행하고, AuthService.withDraw를 호출하지 않습니다.
문서와 실제 동작을 일치시키기 위해서는:
AuthController.withDraw에서authService.withDraw(userDetails.getId())를 호출해 soft delete를 수행하거나,- (만약 의도적으로 아직 미구현이라면) 설명을 수정해 현재 동작을 정확하게 표현해야 합니다.
현재 상태는 API 계약과 구현이 어긋난 상태이므로 정리가 필요해 보입니다.
Also applies to: 17-17, 38-42
🤖 Prompt for AI Agents
In src/main/java/team/wego/wegobackend/auth/presentation/AuthControllerDocs.java
around lines 8, 17 and 38-42, the Javadoc/description claims "DB Soft Delete +
refreshCookie removal" but the actual AuthController.withDraw implementation
only removes the refresh cookie and does not call AuthService.withDraw; either
update the controller to call authService.withDraw(userDetails.getId()) before
removing the cookie so the soft-delete is performed, or update the docs text to
accurately reflect that only the refresh cookie is removed (no DB soft delete);
pick one approach, implement the corresponding change, and keep the method
signature/comments consistent with the chosen behavior.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
src/main/java/team/wego/wegobackend/auth/application/AuthService.java (1)
111-123: 회원탈퇴 서비스 트랜잭션 및 soft delete 구현이 요구사항에 부합합니다클래스가
@Transactional(readOnly = true)인데,withDraw에 별도@Transactional을 붙여서 쓰기 트랜잭션을 보장한 점이 좋습니다.user.updatedeleted(true)로 soft delete 플래그만 변경하는 구조도 회원탈퇴 요구사항에 맞습니다.추가로, 메서드명은 일반적으로
withdraw로 쓰는 편이 많으니, 추후 리팩터링 시 컨트롤러/Docs와 함께 이름을 정리해 두면 가독성이 더 좋아질 것 같습니다.src/main/java/team/wego/wegobackend/auth/presentation/AuthController.java (1)
88-103: 회원탈퇴 엔드포인트가 서비스 로직과 잘 연결되었습니다
@DeleteMapping("/withdraw")에서@AuthenticationPrincipal CustomUserDetails로 본인 식별 후authService.withDraw(userDetails.getId())를 호출하고, 이어서 refresh 토큰 쿠키까지 제거하는 흐름이 요구사항(soft delete + 토큰 정리)에 맞게 잘 구성되어 있습니다.선택적으로는:
- 메서드명/엔드포인트명을
withdraw로 통일(서비스/Docs 포함)하거나,- DELETE 응답을
204 No Content+ body 없음 패턴으로 맞추는 등API 일관성을 위한 소규모 리팩터링을 고려해 볼 수 있겠습니다만, 현재 구현도 기능적으로는 문제 없어 보입니다.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
src/main/java/team/wego/wegobackend/auth/application/AuthService.java(3 hunks)src/main/java/team/wego/wegobackend/auth/presentation/AuthController.java(5 hunks)src/main/java/team/wego/wegobackend/common/security/SecurityEndpoints.java(1 hunks)
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-12-07T11:11:53.287Z
Learnt from: Be-HinD
Repo: WeGo-Together/WeGo_BackEnd PR: 32
File: src/test/http/auth/auth-api.http:25-27
Timestamp: 2025-12-07T11:11:53.287Z
Learning: IntelliJ HTTP client (.http files) automatically manages cookies between requests in the same file. When reviewing .http test files, a refresh token endpoint test does not need an explicit Cookie header because cookies from previous requests (e.g., login) are automatically included by the IDE.
Applied to files:
src/main/java/team/wego/wegobackend/auth/presentation/AuthController.java
🧬 Code graph analysis (1)
src/main/java/team/wego/wegobackend/auth/application/AuthService.java (2)
src/main/java/team/wego/wegobackend/user/exception/UserNotFoundException.java (1)
UserNotFoundException(6-11)src/main/java/team/wego/wegobackend/auth/exception/UserNotFoundException.java (1)
UserNotFoundException(6-11)
🪛 ast-grep (0.40.0)
src/main/java/team/wego/wegobackend/auth/presentation/AuthController.java
[warning] 148-148: The application does not appear to verify inbound requests which can lead to a Cross-site request forgery (CSRF) vulnerability. If the application uses cookie-based authentication, an attacker can trick users into sending authenticated HTTP requests without their knowledge from any arbitrary domain they visit. To prevent this vulnerability start by identifying if the framework or library leveraged has built-in features or offers plugins for CSRF protection. CSRF tokens should be unique and securely random. The Synchronizer Token or Double Submit Cookie patterns with defense-in-depth mechanisms such as the sameSite cookie flag can help prevent CSRF. For more information, see: [Cross-site request forgery prevention](https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Req\ uest_Forgery_Prevention_Cheat_Sheet.html).
Context: response.addCookie(deleteCookie);
Note: [CWE-352] Cross-Site Request Forgery (CSRF). [REFERENCES]
- https://stackoverflow.com/questions/42717210/samesite-cookie-in-java-application
(cookie-missing-samesite-java)
🔇 Additional comments (2)
src/main/java/team/wego/wegobackend/common/security/SecurityEndpoints.java (1)
5-18: PUBLIC_PATTERNS 세분화로 인증 경계가 명확해졌습니다기존
"/api/v*/auth/**"와일드카드를 제거하고,signup/login/refresh만 공개로 두어withdraw(및logout)가 반드시 인증된 사용자만 접근하도록 한 설계가 적절해 보입니다. 회원탈퇴 API 보안 요구사항과도 잘 맞습니다.src/main/java/team/wego/wegobackend/auth/presentation/AuthController.java (1)
75-86: Refresh 토큰 쿠키 삭제 로직 공통화가 깔끔합니다
logout에서 직접 쿠키를 조작하던 부분을deleteRefreshTokenCookie헬퍼로 분리해, 회원탈퇴와 로그아웃이 동일한 속성(이름, path, HttpOnly, Secure, SameSite=Strict)으로 쿠키를 제거하도록 만든 점이 좋습니다. 중복 제거 + 보안 속성 일관성 모두 확보되어 유지보수성이 높아졌습니다.Also applies to: 138-150
1 participant
📝 Pull Request
📌 PR 종류
해당하는 항목에 체크해주세요.
✨ 변경 내용
회원탈퇴 API 개발
v1 팔로우 등록/취소 관련 카운트 업데이트 로직 추가
🔍 관련 이슈
해당 PR이 해결하는 이슈가 있다면 연결해주세요.
Closes #59
🧪 테스트
변경된 기능에 대한 테스트 범위 또는 테스트 결과를 작성해주세요.
🚨 확인해야 할 사항 (Checklist)
PR을 제출하기 전에 아래 항목들을 확인해주세요.
🙋 기타 참고 사항
Summary by CodeRabbit
새로운 기능
개선사항
✏️ Tip: You can customize this high-level summary in your review settings.