[Feature] 로그인 UI 구성 및 카카오 소셜 로그인 구현 #22
Conversation
- 로그인 화면 UI 구성 - 카카오 로그인 버튼 추가 - Near 로고 및 타이틀 이미지 추가 - 관련 문자열 리소스 추가 - 라이트/다크 모드에 따른 상태바 아이콘 색상 조정 - 현재는 라이트모드로 고정
- AuthRepository 및 AuthService 인터페이스 정의 - DataStore를 사용한 토큰 관리 및 AuthRepositoryImpl 구현 - 소셜 로그인 요청/응답 데이터 클래스(SocialLoginRequest, LoginResponse, LoginResult) 추가 - 로그인 관련 ProviderType enum 정의 - LoginViewModel에 소셜 로그인 로직 및 UI 상태 관리 추가 - DI 모듈(RepositoryModule, ServiceModule)에 관련 의존성 주입 설정
- `build.gradle.kts` 파일에 카카오 네이티브 앱 키 추가 - `NearApplication.kt` 파일에 카카오 SDK 초기화 코드 추가 - `LoginScreen.kt` 파일에 카카오 로그인 로직 구현 및 UI 연동 - `AndroidManifest.xml` 파일에 카카오 로그인 콜백을 위한 Activity 및 intent-filter 추가
- 카카오 SDK를 사용하여 카카오 로그인 기능 구현 - SocialLoginDataSource 인터페이스 및 KakaoDataSource 구현체 추가 - SocialLoginProcessor를 통해 소셜 로그인 방식 동적 선택 - AuthRepository에 performSocialLogin 메서드 추가하여 providerType에 따라 로그인 처리 분기 - LoginViewModel에서 performLogin 메서드를 통해 소셜 로그인 요청 - LoginScreen에 카카오 로그인 버튼 추가 및 로그인 로직 연동
DataStoreModule을 AuthRepositoryImpl에서 별도의 파일로 분리했습니다.
- DataStore를 사용한 토큰 저장 및 관리 클래스 (`TokenPreferences`) 추가 - 토큰 갱신 요청 및 응답 모델 (`TokenRefreshRequest`, `TokenRefreshResponse`) 추가 - `AuthRepository` 및 `AuthRepositoryImpl`에 토큰 갱신 로직 추가 - `TokenInterceptor`에서 Authorization 헤더를 동적으로 추가하고, 인증이 필요 없는 요청은 제외하도록 수정 - `LoginResponse` 모델에서 `refreshTokenInfo`를 `refreshToken`으로 변경 - `AuthService`에 토큰 갱신 API (`/auth/renew`) 인터페이스 추가
- `AuthRepositoryImpl`
- 소셜 로그인 시 만료 시간 계산 및 저장 로직 추가
- 토큰 갱신 재시도 로직 (`refreshTokenWithRetry`) 추가
- 401 에러 메시지 수정
- `TokenPreferences`
- 토큰 만료 시간 (`expires_at`) 저장 및 조회 기능 추가
- 토큰 만료 여부 확인 (`isTokenExpired`) 기능 추가
- 액세스 토큰 관찰 (`observeAccessToken`) 기능 추가
- 기존 `saveAccessToken`, `saveRefreshToken` 메서드 삭제
- `TokenRefreshResponse`, `LoginResponse`
- `refreshToken` 필드를 `refreshTokenInfo` (객체)로 변경하여 만료 시간 정보 포함
- `TokenInterceptor`
- 자동 토큰 갱신 및 재시도 로직 구현
- 토큰 만료 시간 기반의 유효성 검사 로직 추가
- 토큰 변화를 관찰하여 실시간으로 `currentToken`, `tokenExpiresAt` 업데이트
- 인증 제외 경로를 `AuthEndpoint` enum으로 관리
- 토큰 갱신 실패 시 토큰 삭제 처리
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Summary of Changes
Hello @stopstone, 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!
이 Pull Request는 애플리케이션에 카카오 소셜 로그인 기능을 통합하고, 사용자 인증 토큰을 효율적으로 관리하기 위한 견고한 아키텍처를 구축합니다. 새로운 로그인 UI와 함께, 토큰 저장, 갱신, 자동 주입 등의 기능을 구현하여 사용자 경험을 개선하고 보안을 강화하는 데 중점을 두었습니다. 이는 향후 다양한 소셜 로그인 옵션과 인증 관련 기능 확장을 위한 기반을 마련합니다.
Highlights
- 카카오 소셜 로그인 구현: 카카오 SDK를 활용하여 소셜 로그인 기능을 구현했습니다. 카카오톡 앱이 설치되어 있으면 앱으로 로그인하고, 없으면 카카오 계정으로 로그인하는 로직이 포함되어 있습니다.
- 인증 및 토큰 관리 시스템 도입: DataStore를 활용하여 액세스 토큰과 리프레시 토큰을 안전하게 저장하고 관리하는
TokenPreferences클래스를 추가했습니다. 이를 통해 사용자 로그인 상태를 유지하고 토큰 만료 시 자동으로 갱신하는 로직을 구현했습니다. - 인증 관련 API 및 Repository 계층 추가: 소셜 로그인 및 토큰 갱신을 위한
AuthService인터페이스와AuthRepository인터페이스 및 구현체를 추가하여 인증 관련 비즈니스 로직을 분리하고 관리합니다. - 동적 소셜 로그인 처리 로직:
SocialLoginDataSource인터페이스와SocialLoginProcessor를 도입하여 다양한 소셜 로그인 제공자(현재는 카카오)를 유연하게 확장하고 처리할 수 있는 전략 패턴을 적용했습니다. - 로그인 화면 UI 및 Navigation 추가: 새로운 로그인 화면 (
LoginScreen,LoginViewModel)과 해당 화면으로의 내비게이션 (LoginNavigation)을 추가하여 사용자 인증 플로우를 완성했습니다. 앱 시작 시 로그인 화면으로 이동하도록NearNavHost를 업데이트했습니다. - 네트워크 요청에 토큰 자동 주입 및 갱신:
TokenInterceptor를 개선하여 저장된 액세스 토큰을 모든 API 요청의Authorization헤더에 자동으로 추가하도록 했습니다. 또한, 401 에러 발생 시 리프레시 토큰을 사용하여 액세스 토큰을 갱신하고, 리프레시 토큰마저 만료되면 모든 토큰을 삭제하는 로직을 포함했습니다.
Using Gemini Code Assist
The 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 in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.
| Feature | Command | Description |
|---|---|---|
| Code Review | /gemini review |
Performs a code review for the current pull request in its current state. |
| Pull Request Summary | /gemini summary |
Provides a summary of the current pull request in its current state. |
| Comment | @gemini-code-assist | Responds in comments when explicitly tagged, both in issue comments and review comments. |
| Help | /gemini help |
Displays a list of available commands. |
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 .gemini/ folder in the base of the repository. Detailed instructions can be found here.
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
-
Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩
There was a problem hiding this comment.
Code Review
이번 PR은 카카오 소셜 로그인 기능 구현과 관련된 전반적인 아키텍처 수정을 포함하고 있습니다. Strategy 패턴을 사용한 소셜 로그인 처리, DataStore를 이용한 토큰 관리, Hilt를 통한 의존성 주입 등 좋은 설계 원칙을 적용하셨습니다. 몇 가지 개선점을 제안드립니다. TokenInterceptor의 비동기 처리 방식은 경쟁 상태를 유발할 수 있어 수정이 필요하며, 토큰 갱신 로직을 추가하면 사용자 경험을 더 향상시킬 수 있습니다. 또한, 로그인 실패 시 사용자에게 에러를 표시하는 로직이 누락되어 추가해야 합니다. 자세한 내용은 각 파일에 남긴 코멘트를 참고해주세요.
| // 401 에러인 경우 토큰 삭제 | ||
| if (response.code == 401 && validToken != null) { | ||
| handleTokenExpired() | ||
| } |
There was a problem hiding this comment.
현재 인터셉터는 401 에러 발생 시 토큰을 삭제하기만 하고, 토큰 갱신을 시도하지 않습니다. AuthRepository에 이미 토큰 갱신 로직(refreshToken)이 구현되어 있으므로, 인터셉터에서 401 에러를 받으면 토큰 갱신을 시도하고 원래 요청을 재시도하는 로직을 추가하는 것이 좋습니다. OkHttp의 Authenticator를 사용하면 이 로직을 더 깔끔하게 구현할 수 있습니다. 이렇게 하면 사용자 경험이 향상되고 불필요한 재로그인을 방지할 수 있습니다.
| private fun observeTokenChanges() { | ||
| coroutineScope.launch { | ||
| try { | ||
| // 초기 토큰 로드 | ||
| currentToken = tokenPreferences.getAccessToken() | ||
| tokenExpiresAt = tokenPreferences.getTokenExpiresAt() | ||
|
|
||
| // 토큰 변화 실시간 관찰 | ||
| tokenPreferences.observeAccessToken().collect { token -> | ||
| currentToken = token | ||
| // 토큰이 변경되면 만료 시간도 다시 로드 | ||
| if (token != null) { | ||
| tokenExpiresAt = tokenPreferences.getTokenExpiresAt() | ||
| } else { | ||
| tokenExpiresAt = null | ||
| } | ||
| } | ||
| } catch (e: Exception) { | ||
| currentToken = null | ||
| tokenExpiresAt = null | ||
| } | ||
| } | ||
| } |
There was a problem hiding this comment.
init 블록에서 코루틴을 사용해 비동기적으로 토큰을 로드하고 관찰하는 방식은 intercept 동기 메소드와 함께 사용할 때 경쟁 상태(race condition)를 유발할 수 있습니다. 첫 네트워크 요청이 토큰을 로드하기 전에 발생하여 인증 헤더 없이 전송될 수 있습니다. 또한, currentToken과 tokenExpiresAt 변수가 여러 스레드에서 접근되지만 @Volatile로 선언되지 않아 메모리 가시성 문제가 발생할 수 있습니다. runBlocking을 사용하여 intercept 내에서 토큰을 동기적으로 가져오거나, Authenticator를 구현하여 토큰 갱신을 처리하는 것을 고려해보세요.
| onShowErrorSnackBar: (throwable: Throwable?) -> Unit, | ||
| ) { |
There was a problem hiding this comment.
loginNavGraph의 onShowErrorSnackBar 파라미터가 LoginRoute로 전달되지 않아 사용되지 않고 있습니다. LoginViewModel에서는 로그인 실패 시 _errorEvent를 통해 에러를 보내고 있지만, UI 단에서 이 이벤트를 수집하여 사용자에게 에러 메시지(예: 스낵바)를 보여주는 로직이 누락되었습니다. 로그인 실패 시 사용자에게 적절한 피드백이 제공되지 않으므로, LoginRoute에서 viewModel.errorEvent를 수집하고 onShowErrorSnackBar를 호출하도록 구현해야 합니다.
| private suspend fun loginWithKakaoTalk(context: Context): String = | ||
| suspendCancellableCoroutine { continuation -> | ||
| UserApiClient.instance.loginWithKakaoTalk(context) { token, error -> | ||
| when { | ||
| error != null -> { | ||
| if (error is ClientError && error.reason == ClientErrorCause.Cancelled) { | ||
| continuation.resume("") | ||
| } else { | ||
| UserApiClient.instance.loginWithKakaoAccount(context) { retryToken, retryError -> | ||
| handleLoginResult(retryToken, retryError, continuation) | ||
| } | ||
| } | ||
| } | ||
| token != null -> continuation.resume(token.accessToken) | ||
| else -> continuation.resume("") | ||
| } | ||
| } | ||
| } | ||
|
|
||
| private suspend fun loginWithKakaoAccount(context: Context): String = | ||
| suspendCancellableCoroutine { continuation -> | ||
| UserApiClient.instance.loginWithKakaoAccount(context) { token, error -> | ||
| handleLoginResult(token, error, continuation) | ||
| } | ||
| } |
There was a problem hiding this comment.
loginWithKakaoTalk 및 loginWithKakaoAccount 함수에서 context를 파라미터로 받고 있지만, KakaoDataSource 클래스는 이미 생성자에서 context를 주입받고 있습니다. 불필요한 파라미터 전달을 제거하고 클래스 프로퍼티인 this.context를 직접 사용하여 코드를 더 간결하게 만들 수 있습니다.
private suspend fun loginWithKakaoTalk(): String =
suspendCancellableCoroutine { continuation ->
UserApiClient.instance.loginWithKakaoTalk(context) { token, error ->
when {
error != null -> {
if (error is ClientError && error.reason == ClientErrorCause.Cancelled) {
continuation.resume("")
} else {
UserApiClient.instance.loginWithKakaoAccount(context) { retryToken, retryError ->
handleLoginResult(retryToken, retryError, continuation)
}
}
}
token != null -> continuation.resume(token.accessToken)
else -> continuation.resume("")
}
}
}
private suspend fun loginWithKakaoAccount(): String =
suspendCancellableCoroutine { continuation ->
UserApiClient.instance.loginWithKakaoAccount(context) { token, error ->
handleLoginResult(token, error, continuation)
}
}| suspend fun hasValidTokens(): Boolean { | ||
| val accessToken = getAccessToken() | ||
| return !accessToken.isNullOrBlank() && !isTokenExpired() | ||
| } |
There was a problem hiding this comment.
hasValidTokens 함수 내에서 getAccessToken()과 isTokenExpired()를 각각 호출하고 있어 DataStore에서 데이터를 두 번 읽어오게 됩니다. 이는 비효율적일 수 있습니다. dataStore.data.first()를 한 번만 호출하여 필요한 모든 값을 가져와서 사용하는 것이 좋습니다. 예를 들어, 다음과 같이 수정할 수 있습니다:
suspend fun hasValidTokens(): Boolean {
val prefs = dataStore.data.first()
val accessToken = prefs[accessTokenKey]
if (accessToken.isNullOrBlank()) return false
val expiresAt = prefs[expiresAtKey]
val isExpired = expiresAt == null || System.currentTimeMillis() >= expiresAt
return !isExpired
}| override suspend fun logout() { | ||
| try { | ||
| tokenPreferences.clearAllTokens() | ||
| } catch (exception: Exception) { | ||
| throw exception | ||
| } |
There was a problem hiding this comment.
logout 함수 내의 try-catch 블록은 예외를 잡아서 다시 던지는 역할만 하고 있어 불필요합니다. 코드를 더 간결하게 만들기 위해 try-catch 블록을 제거하는 것이 좋습니다.
override suspend fun logout() {
tokenPreferences.clearAllTokens()
}| private fun calculateExpiresIn(expiresAtString: String?): Long? { | ||
| return expiresAtString?.let { expiresAt -> | ||
| val dateFormat = SimpleDateFormat("yyyy-MM-dd HH:mm:ss", Locale.getDefault()) | ||
| val expiresAtTime = dateFormat.parse(expiresAt) | ||
| val currentTime = System.currentTimeMillis() | ||
| ((expiresAtTime?.time ?: currentTime) - currentTime) / 1000 // 초 단위로 변환 | ||
| } | ||
| } |
There was a problem hiding this comment.
SimpleDateFormat은 스레드에 안전하지 않아(not thread-safe) 멀티스레드 환경에서 잠재적인 문제를 일으킬 수 있습니다. minSdk가 27 이상이므로 API 레벨 26부터 사용 가능한 java.time 패키지를 사용하는 것이 더 현대적이고 안전한 방법입니다.
private fun calculateExpiresIn(expiresAtString: String?): Long? {
return expiresAtString?.let { expiresAt ->
try {
val formatter = java.time.format.DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss")
val expiresAtTime = java.time.LocalDateTime.parse(expiresAt, formatter)
val expiresAtMillis = expiresAtTime.atZone(java.time.ZoneId.systemDefault()).toInstant().toEpochMilli()
(expiresAtMillis - System.currentTimeMillis()) / 1000 // 초 단위로 변환
} catch (e: java.time.format.DateTimeParseException) {
null
}
}
}- `TokenAuthenticator`를 구현하여 401 에러 발생 시 토큰 갱신 및 재요청 로직 추가 - `TokenInterceptor`에서 토큰 만료 처리 로직 제거 (Authenticator에서 처리) - `OkHttpClient`에 `TokenAuthenticator` 적용
- `TokenManager` 클래스를 추가하여 토큰 저장, 조회, 갱신 로직을 중앙에서 관리합니다. - `TokenAuthenticator`, `AuthRepositoryImpl`, `TokenInterceptor`에서 `TokenManager`를 사용하도록 수정하여 토큰 관리 책임을 위임합니다. - `AuthRepositoryImpl`에서 중복된 토큰 관련 로직 (만료 시간 계산 등)을 제거하고 `TokenManager`의 기능을 사용합니다. - `TokenAuthenticator`에서 `runBlocking`을 사용하여 `suspend` 함수를 호출하도록 수정했습니다. - `TokenInterceptor`에서 `runBlocking`을 사용하여 토큰을 가져오고, 토큰 변화를 관찰하는 로직을 제거하여 `TokenManager`에 의존하도록 단순화했습니다.
카카오 로그인 시 context를 전역으로 참조하도록 변경
- DataStore에서 직접 토큰 및 만료 시간을 가져와서 유효성 검사 - `isTokenExpired()` 메서드 호출 제거 및 로직 통합
- SimpleDateFormat에서 java.time.LocalDateTime으로 변경하여 스레드 안전성 확보 - DateTimeParseException 발생 시 null 반환하도록 수정
rhkrwngud445
left a comment
rhkrwngud445
left a comment
There was a problem hiding this comment.
첫 PR 고생하셨습니다!👍
궁금한 점과 개선해볼만한 점 위주로 남겼습니다!
수정 대신 반박 코멘트도 좋습니다 차차 코드 스타일 맞춰가요😀
Near/app/src/main/java/com/alarmy/near/data/datasource/KakaoDataSource.kt
Show resolved
Hide resolved
|
|
||
| data class LoginResult( | ||
| val isSuccess: Boolean, | ||
| val accessToken: String? = null, |
There was a problem hiding this comment.
뷰로 보내는 모델로 보입니다! accessToken과 refreshToken이 포함되어야 할까요?
| } | ||
|
|
||
| companion object { | ||
| enum class AuthEndpoint(val path: String) { |
There was a problem hiding this comment.
companion object 내에서 enum class로 선언주신 이유가 있을까요?
There was a problem hiding this comment.
1. enum으로 작성한 이유
우선 헤더가 필요없는 인증 관련 엔트포인트를 enum으로 처리하고 싶었습니다!
그렇지 않으면 .contains.contains로 점차 늘어날 것 같아서요..!
2. companion 내부에 작성한 이유
그렇다고 model이나 다른 파일로 분리하기엔 아직까지는 내부에서만 활용되는 상수라고 판단하여
companion 안에 넣어두었습니다.
코멘트
외부에서 활용될 수 있도록 분리하는 것이 좋을까요?
이 부분에 대해서는 감이 잘 서지 않네요..!
There was a problem hiding this comment.
답변 감사합니다!
저는 분리되는게 좋은 것 같아요! 추후 service단의 엔드포인트를 enum으로 관리할 때 재활용성이나 관리측면에서 이점이 있을 것 같아요!
추가적으로 enum이 싱글톤으로 동작하다보니, companion object 내의 선언이 의미가 모호해질 수 있을 것 같아요!
| TOKEN_RENEW("/auth/renew"); | ||
|
|
||
| companion object { | ||
| val EXCLUDED_PATHS = listOf( |
There was a problem hiding this comment.
enum의 entries 속성을 사용하면 리스트를 뽑아올 수 있습니다!
AuthEndpoint.entries 형식으로요!
Near/app/src/main/java/com/alarmy/near/data/datasource/KakaoDataSource.kt
Show resolved
Hide resolved
|
|
||
| @Binds | ||
| @IntoSet | ||
| abstract fun bindKakaoDataSource(kakaoDataSource: KakaoDataSource): SocialLoginDataSource |
There was a problem hiding this comment.
repository와 DataSource는 같은 추상화 레벨로 보기 어려워 보입니다!
별도의 DI로 구성하는 것은 어떨까요?
There was a problem hiding this comment.
맞는 말씀입니다! 이건 바로 수정할게요!
코드를 여기저기 옮겨쓰다보니... 꼼꼼하지 못했던 것 같아요 감사합니다!!
| class SocialLoginProcessor | ||
| @Inject | ||
| constructor( | ||
| private val socialLoginDataSources: Set<@JvmSuppressWildcards SocialLoginDataSource>, |
There was a problem hiding this comment.
Set과 JvmSuppressWildcards를 적용주신 이유가 궁금합니다!
There was a problem hiding this comment.
1. Set을 적용한 이유
현재는 카카오 로그인 뿐이지만 추후 다른 소셜 로그인을 확장하기 쉽게 socialLoginDataSources를 구성했습니다!
이때 List보다는 중복을 방지할 수 있다는 차원에서도 Set이 명확할 것 같아 Set으로 반환하였습니다
2. JvmSuppressWildcards를 적용한 이유
// Kotlin에서 이렇게 쓰면
val dataSources: Set
// JVM 바이트코드에서는 이렇게 변환돼요
Set<? extends SocialLoginDataSource>
여기서 ?는 wildcard로, "정확한 타입을 모르지만 SocialLoginDataSource의 하위 타입들"이라는 의미입니다.
이는 Kotlin의 타입 안전성을 위한 공변성 때문인데,
Dagger와 Hilt는 Java로 작성된 라이브러리라서 이런 wildcard 타입을 제대로 처리하지 못합니다.
바인딩할 때 "어? 이게 정확히 어떤 타입인지 모르겠네?" 하면서 에러가 발생할 가능성이 있어,
@JvmSuppressWildcards 어노테이션을 사용해 wildcard 생성을 억제하여 Set로 그대로 변환되도록 했습니다.
이렇게 하면 Dagger가 정확한 타입을 인식하고 올바르게 의존성 주입을 할 수 있어요
어노테이션을 사용하지 않으면 의존성 에러가 발생하더라구요!!
There was a problem hiding this comment.
이해가 쏙쏙 되네요! 상세한 답변 감사합니다!
| @Inject | ||
| constructor( | ||
| private val tokenPreferences: TokenPreferences, | ||
| private val authServiceProvider: Provider<AuthService>, // Provider로 지연 주입 |
There was a problem hiding this comment.
Provider로 순횐참조를 해결할 수 있군요! 배워갑니다!
There was a problem hiding this comment.
저도 이번에 알게 되었어요!
지연 주입이 가능하다고 하는데, 어떤 이점이 더 있는지는 더 알아봐야 겠습니다!! :D
- LoginResult 모델을 제거하고 Result<Unit>을 사용하도록 수정
- 기존 TokenInterceptor 내부에 있던 AuthEndpoint enum을 별도의 파일로 분리하여 관리하도록 수정했습니다. - 이를 통해 TokenInterceptor는 인증 로직에만 집중하고, 인증 예외 경로는 AuthEndpoint enum에서 관리하도록 역할을 분리했습니다.
KakaoDataSource를 SocialLoginDataSource로 바인딩하는 로직을 RepositoryModule에서 DataSourceModule로 이동했습니다.
작업 내용
카카오 소셜 로그인 구현 및 토큰 관리
확인 방법
키 해시값 확인
참고 사항
관련 이슈
Closes #8