Session on Kelly Dev

SniffMEET. AuthManager와 SessionManager의 책임 분리하기

Mon, 10 Feb 2025 00:00:00 +0000

작업 배경

AuthManager와 SessionManager는 서로 매우 밀접하게 연관된 작업을 한다. AuthManager는 사용자의 계정 인증을 담당하고 세션을 받아오며, SessionManager는 그 세션을 관리한다.

하지만 기존 코드에서는 세션 관리를 포함한 대부분의 작업을 AuthManager가 처리하고, SessionManager는 세션을 소유하는 역할만 하고 있었다.

역할 분리

기존에는 AuthManager에서 세션 갱신, 복원, 저장, 로드 작업을 처리하고 있었고, SessionManager는 세션의 만료 여부 확인과 세션 객체를 소유하는 역할만 맡고 있었다.

// AuthManager 인터페이스 프로토콜
protocol AuthManager {
 static var shared: AuthManager { get }
 var authStateSubject: PassthroughSubject<AuthState, Never> { get set }
 func signInAnonymously() async throws
 func restoreSession() async throws
 func refreshSession() async throws
 func loadTokens() throws
}

// SessionManager 클래스
final class SessionManager {
 static let shared = SessionManager()
 var session: SupabaseSession?
 var isExpired: Bool {
 guard let session else { return true }
 // 세션 만료를 파악할 때는 30초의 여유시간을 줍니다.
 return Date(timeIntervalSince1970: TimeInterval(session.expiresAt + 30)) < Date()
 }
 private init() {}
}

그래서 세션 관리는 SessionManager, 인증은 AuthManager가 맡도록 기능을 다시 정의했다.

SniffMEET. 세션 갱신과 정보 접근을 SessionManager에 캡슐화하기

Mon, 10 Feb 2025 00:00:00 +0000

SessionManager 사용성 개선

세션을 갱신하는 방법

Supabase 서버와의 통신이 필요할 때, 우선 세션의 유효성을 검증해야 한다.

기존 방식에선 직접 AuthManager의 싱글톤 객체에서 세션을 갱신하는 작업을 했지만

AuthManager와 SessionManager의 역할 명확하게 분리
AuthManager의 싱글톤 해제

와 같은 변화점이 있었고, 기존 AuthManager가 담당하던 세션 갱신, 복원 작업이 SessionManager로 옮겨졌다. SessionManager의 싱글톤 객체에서 세션의 유효성을 체크하는 컴퓨티드 프로퍼티의 부울리언 값을 체크하여 세션을 갱신하는 메소드를 호출하는 방식을 사용했다:

if try SessionManager.shared.isExpired {
 try await SessionManager.shared.refreshSession()
}

이 방식은 SessionManager의 싱글톤 객체 호출이 두 번 일어나고, refreshSession이라는 메소드를 직접 노출해서, SessionManager가 세션을 갱신하는 방법을 직접 노출하는 문제가 있다.

SniffMEET. 세션 저장 메소드를 공개해도 괜찮을까?

Mon, 10 Feb 2025 00:00:00 +0000

세션 저장하기

AuthManager와 SessionManager의 역할을 분리하고 나니, 세션을 받아오는 쪽과 저장하는 쪽이 서로 달라지는 문제가 발생했다.

(AuthManager가 세션도 관리하던)기존 구조에서는 saveSession(for:)가 외부에 노출되어 있지 않았는데, 역할이 옮겨진 뒤에는 AuthManager에서 받아온 세션을 SessionManager로 전달해야 했다.

고민한 점

saveSession(for:)는 사실상 AuthManager가 세션을 받아온 상황에서만 필요한 메소드다.

그런데 이 메소드를 공개하면 캡슐화가 약해진다는 생각을 했고, 다시 AuthManager로 돌리면 SessionManager가 맡아야 할 책임을 되돌리는 것이 되었다.

따라서 몇 가지 방법을 떠올려 봤다.

(최종 선택) saveSession(for:)를 공개한다
saveSession(for:)를 AuthManager로 다시 옮긴다
같은 로직을 AuthManager와 SessionManager에 각각 작성한다
세션이 갱신됐다는 이벤트를 따로 전달할 수 있는 통신 레이어를 만든다

처음에 가장 괜찮아 보였던 건 세션 갱신 이벤트를 따로 전달하는 방식이었다.

Network. 쿠키, 세션

Sun, 02 Feb 2025 00:00:00 +0000

개요

웹 애플리케이션에서 사용자 정보를 저장하고 관리하는 방식, HTTP는 statelessness이기 때문에, 이전 요청에 대한 정보를 기억하지 않는다. 따라서 이 문제를 해결하기 위해 쿠키와 세션이 필요하다.

쿠키

클라이언트에 저장되는 작은 데이터 파일, 서버가 클라이언트에게 데이터를 저장하도록 지시하면, 해당 데이터를 전송하게 됨

용도

사용자 인증 정보 저장 (로그인 상태 유지)
웹사이트 설정 저장
사용자 행동 추적

특징

주기적 전송: 사용자가 특정 사이트에 다시 방문하면 브라우저가 자동으로 쿠키를 서버로 전송함
수명: 유효 기간을 설정할 수 있고, 만료되면 삭제됨, 유효기간이 없으면 브라우저 세션이 종료될 때 삭제
용량: 한 도메인당 쿠키는 4KB 정도로 제한

보안

사용자의 브라우저에 저장되기 때문에 클라이언트에서 조작할 수 있다. 따라서 민감한 데이터는 쿠키에 저장하면 안됨

SniffMEET. 익명 로그인 세션의 생성·복원·갱신 흐름

Thu, 14 Nov 2024 00:00:00 +0000

익명 로그인 생성, 복원, 갱신 로직 구현

JWT, Refresh Token, 세션의 개념이 아직 명확하게 정리되지 않은 상태에서 익명 계정을 먼저 만들게 됐다. 개념이 명확하지 않아서, 세션 관리에 꽤 애를 먹었는데, 앱 재실행 이후에도 익명 계정을 어떻게 이어서 사용할지부터 정리할 필요가 있었다.

생성, 복원, 갱신 로직은 서로 밀접하게 연결되어 있어서, 처음 앱을 실행했을 때와 다시 실행했을 때의 흐름을 먼저 구분해야 했다.

실제 문제 해결 과정

먼저 시점별로 세션 상태를 표로 정리했다.