AuthProvider는 클라이언트(브라우저)에서만 쓰는 지금 로그인한 사용자 상태를 한 군데서 갖고, 필요한 컴포넌트에 넘겨준다.
1. 역할 요약
| 역할 | 설명 |
|---|---|
| 클라이언트 인증 상태 | user, status(loading / authenticated / unauthenticated)를 Context로 보관 |
| 한 번만 호출, 여러 곳에서 사용 | 마운트경로 변경포커스 등에서 /auth/me를 호출하고, 그 결과를 useAuth()로 쓰는 컴포넌트들이 재사용 |
| 클라이언트 전용 | 서버는 serverGET("/auth/me")로 SSR 시 따로 호출. AuthProvider는 브라우저에서 /auth/me를 호출해 헤더마이페이지 등 클라이언트 UI에만 사용 |
2. 실제로 쓰는 곳
- app/layout.tsx
- AuthHeaderNav
- /my, /my/account
- /login
- useCurrentUser (블로그)
3. 서버 인증과의 차이
- 서버(SSR)
- AuthProvider(클라이언트)
페이지별 권한(예: 블로그 수정 버튼)은 서버의 serverGET("/auth/me")가 담당하고, 지금 이 탭에서 로그인한 사람이 누구인지를 클라이언트에서 쓰기 위해 AuthProvider가 있는 구조
그럼 여기서 serverGET("/auth/me"), 사용하는 건 두번 요청하는 거야? useAuth() 이건 언제 사용하는 거야?
1. "두 번 요청"이 맞는지
결론: 역할이 다른 두 번의 인증 확인| 시점 | 누가 | 무엇을 | 목적 |
|---|---|---|---|
| SSR (페이지 그릴 때) | 서버 | serverGET("/auth/me") | 이 요청의 쿠키로 지금 이 사용자가 admin인지 판단 HTML에 새 글 작성 버튼 포함 여부 결정 |
| 클라이언트 (페이지 로드 후) | 브라우저 | clientGET("/auth/me") (AuthProvider의 refetch) | 헤더의 My 페이지 / Log in, 마이페이지 등 클라이언트 UI용 user/status 갱신 |
- 서버 쪽: 브라우저가 /blog 요청을 보내면, 그 요청의 쿠키로 서버가 serverGET("/auth/me")를 한 번 실행합니다. (PHP 호출 0번 또는 1번, 쿠키 없으면 바로 { user: null } 반환)
- 클라이언트 쪽: HTML 받고 React가 붙은 뒤 AuthProvider가 clientGET("/auth/me")를 한 번 호출한다. (브라우저 /api/proxy/auth/me 요청 1번)
- 한 번은 서버에서 (블로그 페이지 SSR용, 버튼 노출 여부)
- 한 번은 클라이언트에서 (헤더전역 로그인 상태용)
2. serverGET("/auth/me") vs useAuth() 언제 뭘 쓰나
- serverGETAuthMeResponse("/auth/me")
- 서버 컴포넌트에서만 사용 (예: app/blog/page.tsx).
- 이 요청의 쿠키로 지금 사용자가 누구인지/권한이 뭔지를 HTML을 만들 때 한 번만 쓰고 싶을 때.
- 블로그 목록처럼 admin이면 버튼을 HTML에 넣고, 아니면 안 넣는 경우에 적합.
- useAuth()
- 클라이언트 컴포넌트에서만 사용 (예: 헤더, /my, 로그인 페이지).
- 브라우저에서 로그인 상태가 바뀔 때마다(로그인/로그아웃, 새로고침, 탭 전환 등) UI를 바꿔야 할 때 쓴다.
- AuthProvider가 클라이언트에서 /auth/me를 호출해서 user/status/refetch를 관리하고, 그걸 useAuth()로 구독하는 구조다.
- 페이지/레이아웃의 SSR 단계에서 이 페이지 HTML에 뭘 넣을지 결정할 때 serverGET("/auth/me") (지금 blog page 2730처럼).
- 이미 내려온 페이지 위에서 지금 로그인한 사람 기준으로 UI를 바꾸거나, 로그인 후 상태 갱신이 필요할 때 useAuth().