Refresh token 로직 추가

[j-nary]

🚩 관련 이슈

• close auth 에러 핸들링 추가 #1079

📋 작업 내용

• refresh token 로직 추가

📌 PR Point

문제 상황

• crewToken 의 만료기간은 10시간인데, refresh 로직이 구현되어있지 않습니다.
• 그렇기에 브라우저를 켜둔 채 10시간이 지나면 새로고침없이는 만료된 토큰 에러가 무한으로 로깅되는 상황입니다.

현재의 토큰 로직

1. playgroundToken 을 localStorage 에서 받아옴

   1. playgroundToken 없으면 login 페이지로 redirect

2. playgroundToken 을 이용해 getCrewToken API 호출하여 crewToken 받아옴

3. 리액트 하이드레이션 에러를 피하기 위해, 해당 과정을 아래와 같이 분기 처리

   // 리액트 하이드레이션 에러를 피하기 위해 사용. 렌더링에 관여하지 않는 코드여서 if 문으로 분기처리
   if (typeof window !== 'undefined') {
     setAccessTokens();
   }
   

해결 방안

해결 방안으로는 서버 만료기간이 10시간이니까, 클라에서는 9시간을 만료시간으로 잡고 refresh 하는 로직을 추가하는 것을 생각하였습니다. 로직 추가를 어디에 하느냐 하는 option은 아래와 같이 두 가지가 있을 것 같습니다.

1. if문 분기처리

   // 리액트 하이드레이션 에러를 피하기 위해 사용. 렌더링에 관여하지 않는 코드여서 if 문으로 분기처리
   if (typeof window !== 'undefined') {
     setAccessTokens();
     setInterval(setAccessTokens, 9 * 60 * 60 * 1000); // 9시간마다 토큰 갱신
   }

2. 컴포넌트 내부

   useEffect(() => {
   	setAccessTokens();
   	const intervalId = setInterval(setAccessTokens, 9 * 60 * 60 * 1000);
   	return () => clearInterval(intervalId);
   }, []);

• 은수님께서 refresh 로직이 추가되기 전에, 첫 번째 방법으로 구현하셨던 이유는 주석에서도 나와있듯이, 클라이언트 환경에서만 실행되도록 보장하면서, 렌더링과 관련없는 부수 효과 코드를 분리함으로써 하이드레이션 에러를 방지하기 위함이라고 보여집니다.
• 하지만, 여기에 setInterval 이라는 refresh 로직을 추가시킴으로써, 컴포넌트 라이프사이클과 독립적으로 실행되어 컴포넌트가 언마운트 되더라도 setInterval 이 계속 남아있어 메모리 누수 위험이 있을 수 있을 것 같습니다.
• 이에, 저는 두 번째 방법을 채택하여 구현하였습니다. useEffect 도 컴포넌트가 마운트된 후에 실행되기 때문에 SSR 환경에서도 안전하게 클라이언트 전용 작업을 수행할 수 있고, 무엇보다 클린업 처리가 가능해서 메모리 누수를 방지할 수 있다고 판단했습니다.
• 다만, 혹시 playgroundToken 으로 연결하던 중에, 리액트 하이드레이션 에러가 발생하여서 if문 분기처리가 불가피했는지에 대한 의견과 혹시 더 좋은 방안이 있을 지에 대한 의견을 듣고 싶습니다!

[height]

Link Height tasks by mentioning a task ID in the pull request title or commit messages, or description and comments with the keyword link (e.g. "Link T-123").

💡Tip: You can also use "Close T-X" to automatically close a task when the pull request is merged.

[eunsukimme]

고생하셨습니다 이진님! 👍

한 가지 궁금한 점) 지금 크루 로그인 v2 API로 내려받는 크루 액세스 토큰은 매번 새로운 토큰을 발급하는 구조인거죠? refresh token 로직 추가이지만 사실상 refresh token 을 사용하진 않고 액세스 토큰만을 취급하는 것 같아서 헷갈려서 확인차 여쭤봐요~

그리고 사소하지만 9 * 60 * 60 * 1000 요런 매직 넘버는 따로 상수로 빼도 괜찮을 것 같아요 ㅎ

[j-nary]

고생하셨습니다 이진님! 👍

한 가지 궁금한 점) 지금 크루 로그인 v2 API로 내려받는 크루 액세스 토큰은 매번 새로운 토큰을 발급하는 구조인거죠? refresh token 로직 추가이지만 사실상 refresh token 을 사용하진 않고 액세스 토큰만을 취급하는 것 같아서 헷갈려서 확인차 여쭤봐요~

@eunsukimme
넵! API 호출할 때마다 매번 새로운 토큰을 발급하는 구조입니다!
playgroundToken 기반이라 refreshToken을 따로 두지 않은 걸로 알고 있습니다!

[eunsukimme]

@j-nary 아하 네~ 이해했어요. 액세스 토큰 갱신 차원에서 refresh 라는 말을 사용하신 거군요.

이슈에 달아주신 슬랙도 잠깐 보고왔는데, 토큰 유효시간이 10시간이라 브라우저 창을 10시간 넘게 띄워두면 이후 요청에 날아가는 토큰은 만료되어 정상 동작 하지 않는 이슈인 것으로 이해했네요(제가 이해한게 맞을까요?). 그렇다면 일단 이 방식으로 해결할 수 있을 것 같네요!

그리고 PR에 남겨주신 질문 중

다만, 혹시 playgroundToken 으로 연결하던 중에, 리액트 하이드레이션 에러가 발생하여서 if문 분기처리가 불가피했는지에 대한 의견과 혹시 더 좋은 방안이 있을 지에 대한 의견을 듣고 싶습니다!

에 대해 답변드리면, 일단 effect 사용을 최소화 하고자 하는 목적이 있었어서 컴포넌트 바깥에서 토큰 초기화 로직을 실행했었어요. 메모리 누수에 대한 생각은 크게 고려하진 않았는데, 말씀해주신 방식이 논리적으로 안전한 방식인 것 같아서 저도 동의해요. 저도 생각해보지 못 한 부분을 말씀해주셔서 감사합니다 💯

[j-nary]

@j-nary 아하 네~ 이해했어요. 액세스 토큰 갱신 차원에서 refresh 라는 말을 사용하신 거군요.

@eunsukimme 헉 맞습니다 제가 용어를 애매하게 사용하여 혼란을 드렸네요!

이슈에 달아주신 슬랙도 잠깐 보고왔는데, 토큰 유효시간이 10시간이라 브라우저 창을 10시간 넘게 띄워두면 이후 요청에 날아가는 토큰은 만료되어 정상 동작 하지 않는 이슈인 것으로 이해했네요(제가 이해한게 맞을까요?).

네! 맞습니다!

저도 동의해요. 저도 생각해보지 못 한 부분을 말씀해주셔서 감사합니다 💯

헉 저야말로 신경써서 확인해주셔서 정말 감사합니다 🙇‍♀️🙇‍♀️🙇‍♀️
auth부분은 dev에서 테스트할 수 없는 부분이라 자문없이 prod에 배포하기 무서웠는데 바쁜 시간 쪼개어 신경써주셔서 감사합니다 !!! 🚀🚀🚀🚀🚀