api 요청 시 만료된 access token에 대한 middleware에서의 처리

우선 output 페이지 이동에 대해선 

 

중간에 access token이 만료될 경우 

refresh token을 통해 재발급 받고 

 

index.ejs 페이지에서 모든 응답에 대해 받은 다음 

재발급 받은 access token을 저장 후, 원래 요청하려면 페이지로 이동시키는 방식을 사용했다.

 

output

• 로그인 되어 있을 시: res.locals에 userInfo (사용자 정보) 저장 및 전달
• 로그인 안되어 있을 시: userInfo 없어서 null 전달

middleware

// access token, refresh token 모두 인증 통과 시
res.locals.userInfo = { 
  id: userInfo.id, 
  name: userInfo.name, 
  point: userInfo.point, 
  isAdmin: userInfo.isAdmin 
};
return next();

router

router.get('/', outputMiddleware, (req, res) => {
  res.render('index', {
    userInfo: res.locals.userInfo ?? null,
  });
});

 

• accss token 만료되고 refresh token만 인증될 시

middleware

return res.render('index', {
  redirect: req.path,
  accessToken: newAccessToken,
});

index.ejs

<script>
window.onload = () => {
  <% if (locals.accessToken) { %>
    document.cookie = 'accessToken=<%= locals.accessToken %>; path=/;';
    location.href = '<%= locals.redirect %>'; 
  <% } %>
};
</script>

 

api

하지만 output과 다르게 api가 문제였다.

output과 처리는 비슷하지만

accss token 만료되고 refresh token만 인증될 시

가 문제가 되었는데, 위에서처럼 index에 render로 보내 access token을 저장하고

다시 요청하려던 path로 재요청 할 수가 없다. 

const getOrdersDoing = () => {
  fetch('/api/orders/doing', {
    method: 'GET',
  })
    .then(async (res) => {
      // ...생략
      // 여기서 우짤거임
    })
};

이런 형태로 요청하고 있고

이게 각 페이지의 JavaScript 파일마다 다른 기능으로 각각 요청중인데

access token만 return할 경우

1. 각각의 fetch의 then에서 access token을 저장해줘야 하고
2. 재요청을 해야 하는데 저장, 수정하는 요청이었을 경우 parameter 값들을 같이 다시 재요청 해야한다.

2번의 경우 요청들이 어차피 document.querySelector로 input의 값을 가져와 보내주기 때문에

일단 해당 함수가 호출되며 같이 들어온 parameter와 함께 그대로 다시 재호출 하는 방법을 사용했다.

 

middleware

return res.status(444).json({
  accessToken: newAccessToken,
});

api_요청.js

fetch('/api/orders', {
    method: 'POST',
    body: formData,
  })
    .then(async (res) => {
      // ...생략
      if (code === 201) {
        location.href = '/mypage';
      } else if (code === 444) {
        document.cookie = `accessToken=${res.accessToken}; path=/;`;
        orderRequest();
      }
    })

 

결과적으론 다행히 모두 재발급 받은 access token을 저장하며 잘 재요청하여 

원하는 응답을 받고 있었다.

임시로 지정해놓은 status code인 444를 출력하며 아래와 같은 흔적을 남기지만..

 

잘되긴 된거 같은데 솔직히 이 방법이 사실 맞는지 모르겠다.

모든 api 요청에 대해 

} else if (code === 444) {
  document.cookie = `accessToken=${res.accessToken}; path=/;`;
  getOrdersWaiting(p);
}

} else if (code === 444) {
  document.cookie = `accessToken=${res.accessToken}; path=/;`;
  takeOrder(orderId);
}

} else if (code === 444) {
  document.cookie = `accessToken=${res.accessToken}; path=/;`;
  getOrdersDoing();
}

} else if (code === 444) {
  document.cookie = `accessToken=${res.accessToken}; path=/;`;
  updateStatus(orderId, status_before, status_after);
}

이러고 있는데 이게 맞나??

 

front-end의 영역인거 같은데 

애초에 bacn-end에서 이렇게 응답을 하니 어쩔 수 없는거 같기도 하고..

 

지금의 나로선 최선의 방법으로 이렇게 구현하긴 했지만

좀 더 나은 방법은 없는지, 조금 있으면 배우게 될 next.js에 가면 해결이 될지 

한 번 두고봐야 겠다. 🥲

 

* 위의 status code 444는 이후 307 redirect 코드로 변경되었다.