1

I have a js client (vuejs) and a backend using DRF both in local.

I use this package to generate the token : https://github.com/davesque/django-rest-framework-simplejwt

I use this package https://www.npmjs.com/package/axios-auth-refresh to handle refresh token logic.

The main goal is to intercept a request when it return a 401 response, perform a refresh token request and then resolve the orginal request with the new token.

It works when the original request is a GET request but not when it is a POST request.

When using a POST request :

The orgin request fall in 401 when the token expire then the interceptor occur but the server respond with 405 method not allowed:

-https://i.stack.imgur.com/wlFmi.jpg

the method from the request from the interceptor does not match the method in the code shown above (line 3 & 4) : as you can see the server receive the payload from the origin request as method of the request :

-https://i.stack.imgur.com/bMJsg.jpg

I found this post : App Script sends 405 response when trying to send a POST request

i try to change the headers as advised but it did not work

How is the payload from the orginal resquest becoming the method of the interceptor when the origin request is a Post request with a payload ?

Here the code from the javascript client : 

const refreshAuthLogic = failedRequest => axios(
  {
    method: 'post',
    url: 'auth/refresh',
    data: { refresh: store.state.token.refresh }
  }).then(tokenRefreshResponse => {
  store.dispatch('refreshToken', tokenRefreshResponse.data)
  return Promise.resolve()
})

const instance = axios.create({
  baseURL: '/api/'
})
instance.interceptors.request.use(config => {
  config.headers.Authorization = `Bearer ${store.state.token.access}`
  return config
})

createAuthRefreshInterceptor(instance, refreshAuthLogic)

EDIT

I manage to get it work but i don't really understand:

  • the problem is related to DJANGO/ DRF and not axios
  • it seems that when a POST request is done and fail ( here with 401) the server keeped the data.

Here the part i can't explain :

  • when the request of the interceptor (to refresh token) hit the server, it messes with the data of previous request.

I had to add a middleware in django to clear the body when the request fails with 401 and it worked for me. But it is not a proper solution i guess.

mg175430
  • 23
  • 6

1 Answers1

2

Unfortunately the lib is loosely mantained and it's flawed in some aspects.

Eg: concurrent requests are not correctly queued when the request is sent with and invalid token but the response arrives when a new token is already issued.

As is, if you look at the lib source, you'll find in the very first lines:

/** @type {Object} */
const defaults = {

    /** @type {Number[]} */
    statusCodes: [
        401 // Unauthorized
    ]
};

This means that only 401 code is managed and the statusCodes are not exported so them remains private.

If you want to continue to use this library you can fork it in order to change what does not fit with your stack or simply copy the source, edit it and use it as a local service.

Mosè Raguzzini
  • 15,399
  • 1
  • 31
  • 43
  • thank you for you answer. I edited my post. I try to figure out why it works when the request intercepted is a GET and not when it is a POST request. And why the server identify the payload from the orignal POST request as the method of the refresh token method. – mg175430 Jul 01 '19 at 16:12
  • additionally I want to point out that a 405 is the wrong error even for a POST if the issue is an invalid access token it should return 401 anyway – Mosè Raguzzini Jul 01 '19 at 16:19