개발자
안녕하세요 NextJS14 에서 JWT 로그인 방식으로 프로젝트 진행중에 있습니다. 현재 AccessToken 만료시 재 갱신하는 로직을 하면서 해결하지 못하는 내용이 있어서 문의 드리립니다. 서버 컴포넌트와 클라이언트 컴포넌트에서 갱신된 AccessToken 을 공유 하는 법에 대해서 어떻게 처리 하셨나요? - app router 사용 - accessToken, refreshToken 쿠키 사용 - fetch 를 이용하여 API 호출 아래 테스트 내용으로 서버 컴포넌트에서 AccessToken 만료되어 갱신되는 경우 클라이언트로 쿠키를 갱신해줄 방법을 모르겠습니다. 너무 CSR 구조로 생각하는거 같기도해서, 이런 경우 어떻게 토큰을 현행화 해서 사용하는지 문의 드립니다. 별도 가이드 문서를 더 찾아보면 서버 컴포넌트에서는 쿠키를 사용하지 말라는 글도 보여서, 방향성을 잘못잡고 있는 느낌도 들고 있습니다. 많은 조언 부탁드립니다!! 테스트 케이스) 1. 서버 <-> 클라이언트 (에러) - 서버 컴포넌트에서 백엔드 API 호출 -> 토큰 만료 -> AccessToken 재 갱신 API 호출 -> 쿠키 set -> 클라이언트에서 백엔드 API 호출(당연히 클라이언트에서는 쿠키가 갱신안되서 에러) 2. 서버 <-> 서버(성공) - 서버 컴포넌트에서 백엔드 API 호출 -> 토큰 만료 -> AccessToken 재 갱신 API 호출-> 쿠키 set -> 서버 백엔드 API 호출 3. 클라이언트 <-> 클라이언트 (성공) - 클라이언트 컴포넌트에서 백엔드 API 호출 -> 토큰 만료 -> AccessToken 재 갱신 API 호출-> 쿠키 set -> 클라이언트 백엔드 API 호출
답변 1
next가 클라이언트(브라우저)와 통신할 수 있는 기회는 현재로서는 2가지 경로입니다. 1. middleware 2. route handler 이 둘 모두 첫번째 파라미터인 request 객체를 통해 쿠키를 조회할 수 있고, cookies 모듈을 통해서도 조회/설정할 수 있습니다. 이 모듈은 서버 컴포넌트에서도 사용할 수 있지만 조회만 가능합니다. 그래서 테스트 케이스 2번의 경우 "쿠키 set"에서 밀어넣은 토큰 정보가 브라우저에서 확인해보면 보이지 않을겁니다. middleware는 페이지를 로드하기 이전에 next 서버에서 가장 먼저 읽는 파일입니다. 따라서 앱의 모든 위치에서 페이지 로딩 전 해야할 공통 작업이 있다면 여기서 처리할 수 있습니다. middleware에서 request 객체를 조회하면 클라이언트의 요청 헤더를 통해 쿠키를 조회할 수 있고, cookies 모듈이나 response 객체를 통해서 쿠키를 설정할 수도 있습니다. 그래서 보통 이 영역에서 토큰을 체크하고 갱신합니다. 지금의 middleware는 요청도 만들어서 보낼 수 있고, 대기도 가능하고, 후처리도 할 수 있습니다. 토큰의 가부 혹은 만료 여부를 판단해 새로운 토큰을 받아 갱신하고, 이 과정 상에 에러가 생긴다면 리디렉션을 실행합니다. route handler에서도 동일하게 request와 response, cookies 모듈을 사용할 수 있습니다. 그러나 페이지가 이미 로딩이 된 이후이므로 도메인의 보호가 불완전합니다. 그래서 보통 middleware를 사용합니다. 단, crud에 의한, 그러니까 사용자에 의한 api호출 시에도 access token의 체크가 필요하고, 갱신까지 필요하다면 보다 복잡한 패턴이 요구됩니다.
지금 가입하면 모든 질문의 답변을 볼 수 있어요!
현직자들의 명쾌한 답변을 얻을 수 있어요.
이미 회원이신가요?
지금 가입하면 모든 질문의 답변을 볼 수 있어요!