문제
배포하기 위해 console을 주석처리하면서 코드 일부가 누락되어 액세스 토큰 재발급에 오류 발생햇다. 그래서 누란된 코드를 다시 추가하였지만 새로 발급된 토큰으로 실패한 이전 요청에 대한 재시도가 이루어지지 않는 문제 발생
시도
요청 성공 후 백엔드 응답 코드 콘솔에서 확인
해결
수정 전
originalConfig.headers["Authorization"]="Bearer "+res.headers.authorization;
originalConfig.headers["Refresh"]= res.headers.refresh;수정 후
originalConfig.headers["authorization"]="Bearer "+res.headers.authorization;
originalConfig.headers["refresh"]= res.headers.refresh;서버로 부터 발급 받는 토큰은 localstorage에 Authorization이라는 이름으로 저장한다. 그래서 나는 localstorage에 저장된 토큰 값으로 재요청을 보낸다고 생각했다. 하지만 여기서 originalConfig는 액세스 토큰이 만료되어 발생한 401 오류로 실패한 원래의 HTTP 요청 설정이다. 다시 말해 localstorage에 저장된 토큰을 사용한 것이 아니라 요청 성공 후 응답 받은 토큰 값을 바로 사용한 것이다.
정리하면
서버로부터 새 액세스 토큰을 성공적으로 받았다면, res.headers.authorization는 그 새로운 토큰을 담고 있을 것이다. 이 값을 originalConfig.headers["authorization"]에 설정함으로써, 실패했던 요청을 재시도하기 전에 해당 요청의 Authorization 헤더를 새로운 유효한 토큰으로 업데이트하는 것하고 서버로 응답받은 값으로 재요청한다.
그렇다면 응답이 성공하고 로컬스토리지에 토큰을 저장하는데 이 저장된 토큰을 하지 않고 응답받은 데이터를 사용하는 걸까??
우선 각각은 사용 목적이 다르다.
localStorage에 토큰을 저장하는 이유는 사용자가 새로고침을 하거나 앱을 다시 방문했을 때 인증 상태를 유지하기 위함이다.
하지만, 재발급 받은 토큰을 가지고 실패한 요청을 재요청하는 경우, 당장 요청을 재시도하는 코드의 실행 컨텍스트에서는 localStorage에 저장하기 전에, 메모리 상의 변수로부터 토큰을 즉시 사용하는 것이 더 효율적일 수 있다.
응답받은 데이터로 직접 재시도하는 것이 좋은 이유
-
즉시성
localStorage에 저장하는 동작은 비동기적일 수 있다. 즉, localStorage에 저장하고 다시 불러오는데 시간이 걸릴 수 있다. 반면, 메모리에서 직접 토큰을 참조하면 그런 지연 없이 바로 재시도할 수 있다. -
동기화
만약 여러 요청이 동시에 실패했다면, 각각의 요청이 동일한 재발급 토큰으로 업데이트되어야 한다. 메모리 상의 변수를 사용하면 이런 동기화 문제를 피할 수 있다. -
일관성: 응답 헤더에서 직접 토큰을 참조함으로써, 서버로부터 받은 최신 정보를 사용한다는 것을 코드상에서 명확히 할 수 있다. 이는 특히 디버깅 시 혼동을 방지하는 데 도움을 준다.
결론적으로, localStorage에 저장된 토큰을 사용하여 요청을 재시도할 수도 있지만, 실패한 요청을 즉시 재시도할 때는 응답에서 직접 토큰을 사용하는 것이 일반적으로 더 안전하고, 빠르며, 오류 가능성을 줄여준다.
