최초 로그인시 토큰이 null로 보내지는 버그

프로젝트 라우팅 구조

Routing.tsx

token을 전역상태로 관리하는데 그 토큰의 변경이 감지되면 알맞게 페이지 리다이렉트를 시키는 구조이다.

 

문제

 

로그인 시 토큰을 발급받고 로컬스토리지에 저장하는데 저장 후 토큰이 감지되고 리다이렉트를 하는데 토큰의 값이 null로 request 된다.

 

문제 해결 과정

 

1. 저장이 되기 전에 리다이렉트 되나?

vscode로 페이지가 라우팅 되기 전, 라우팅 되는 과정, 라우팅 후를 관찰하기 위해 debug를 사용함.
하지만 토큰이 로컬 스토리지에 저장이 되고 라우팅 되는 것을 확인할 수 있었음.

 

2. axios의 인스턴스가 문제인가?

custom 한 api가 문제인가 싶어서 login함수를 만들고 axios로 하드코딩해서 headers에 토큰을 받아서 넘겨줬는데 여전히 null값으로 보내짐.

 

3. 인터셉터가 문제인가?

문제 해결 코드

  instance.interceptors.request.use(
    (config) => {
      const token = localStorage.getItem('token');
      const parsedToken = JSON.parse(token);
      if (token) {
        config.headers.Authorization = `Bearer ${parsedToken}`;
      }
      console.log('interceptor > request', config);
      return config;
    }

config 안에 token, parsedToken을 적어주면 동작한다.

 

하지만, 

  instance.interceptors.request.use(
    const token = localStorage.getItem('token');
    const parsedToken = JSON.parse(token);
    (config) => {
      if (token) {
        config.headers.Authorization = `Bearer ${parsedToken}`;
      }
      console.log('interceptor > request', config);
      return config;
    },

token과 parsedToken을 config 바깥으로 빼주면 역시나 안된다.

eslint로 걸리지도 않고 문법상 문제가 없지만 아무튼 이렇게 하면 안 된다.

 

 

---

 

+ 추가 06/27

 

공부중에 다시 돌아와 코드를 살펴보니 scope와 lifecycle 문제였다..!

 

우선 위 두 코드의 주된 차이점은 token이 함수 내부에서 선언되는 시점에 차이가 있다.

 

제대로 동작하는 첫 번째 코드에서는 'token'과 'parsedToken' 변수는 interceptor의 callback function 내부에 선언되어 있다. 이는 매 request가 발생할 때마다 해당 변수들이 새롭게 선언되고 초기화되는 것을 의미한다. 그래서 request가 발생할 때마다 localStorage에서 'token'을 가져와 parsing하고, 이를 바탕으로 Authorization 헤더를 설정한다.

 

반면에 오류가 나는 코드인 두 번째 코드에서는 'token'과 'parsedToken' 변수는 interceptor의 callback function 외부에 선언되어 있다. 이 경우 변수들은 interceptor가 설정될 때 한 번만 선언되고 초기화된다. 따라서 request가 발생할 때마다 'token'을 새롭게 가져오거나 parsing하지 않는다.

 

이 경우, 사용자의 로그인 상태가 변경되었을 때 새롭게 발급받은 token을 반영하지 못하고, interceptor 설정 시점에서 가져온 초기의 'token' 값만을 계속 사용하게 된다.

 

정리하면, 첫 번째 코드는 매 요청마다 토큰을 새로 가져와서 사용하므로 사용자의 로그인 상태 변경을 실시간으로 반영한다. 반면에 두 번째 코드는 설정 시점의 토큰만을 계속 사용하므로 실시간 변경을 반영하지 못한다. 이러한 차이 때문에 첫 번째 코드가 더욱 적절한 구현이라고 볼 수 있다.