django 세팅에서 SIMPLE_JWT 딕셔너리에 토큰에 대한 설정을 할 수 있었다.
여기서 access token의 수명을 정할 수 있는데, 이 기간이 지난 토큰은 인증에 실패한다.
토큰을 계속 새로 제공해야 보안에 강할 것 같다. 아마?
SimpleJWT의 TokenRefreshView를 이용해 refresh token을 제출하면 새로 access token을 제공한다.
갱신은 언제? access token이 만료될 때마다.
사용자가 요청을 할 때 만료된 토큰을 사용하면 401 Unauthorized인 response를 얻게 된다.
매 axios를 사용할 때마다 catch에 갱신코드를 작성하면 중복이 심하다. 따라서 인스턴스 내에 있는 Interceptor를 이용해야 한다.
django 세팅에서 SIMPLE_JWT 딕셔너리에 토큰에 대한 설정을 할 수 있었다. 여기서 access token의 수명을 정할 수 있는데, 이 기간이 지난 토큰은 인증에 실패한다. 토큰을 계속 새로 제공해야 보안에 강할 것 같다. 아마?
SimpleJWT의 TokenRefreshView를 이용해 refresh token을 제출하면 새로 access token을 제공한다. 갱신은 언제? access token이 만료될 때마다. 사용자가 요청을 할 때 만료된 토큰을 사용하면 401 Unauthorized인 response를 얻게 된다. 매 axios를 사용할 때마다 catch에 갱신코드를 작성하면 중복이 심하다. 따라서 인스턴스 내에 있는 Interceptor를 이용해야 한다.
Axios Instance
요청하기 직전(request), 응답을 받은 직후(response) 시점에서 처리를 할 수 있다.
401 Unauthorized 응답을 받았다면 인증에 실패한 것인데 몇 가지 경우가 있다.
토큰이 없는 경우 (로그아웃 상태)
access token, refresh token 둘 다 없다. 이를 얻기 위해서는 로그인 뿐이다. 로그인페이지로 이동되도록 한다.
토큰이 만료된 경우 (로그인 상태)
일단 401에러가 캐치되어 있다.
axios.interceptors.response.use에서 제일 먼저 캐치할 수 있다. 401에러라면 갱신요청을 한다. 그리고 갱신요청이 실패했을 때 또다시 갱신요청을 하지 않기 위해 트릭을 넣는다. 이 외에는 잘 모르겠다.이 프로젝트에서는 라우터를 이용해 컴포넌트를 이동할 때마다 access token을 검증한다. path마다 meta 값으로 인증이 필요한 컴포넌트를 선별할 수 있다. 이 컴포넌트들만 검증한다. ... 사실 매 라우팅마다 인증해야되는것 같다.
TODO