통신에 token이 관여할 때 취할 수 있는 전략이 있습니다. interceptor가 token 검증을 할 때 처리해볼 수 있는 문제 해결 방식입니다.
요약하면 node환경에서도 token을 저장합니다.
MSW와 axios interceptor
문제: 모의로 보내는 요청을 차단하지 않게 모의로 만들 토큰이 필요
interceptor가 토큰이 없으면 요청을 차단합니다. 하지만 모의로 보내는 요청을 차단하지 않게 모의로 만들 토큰이 필요했습니다.
const authClient: AxiosInstance = axios.create({
baseURL: BASE_URL,
headers: {
'Content-Type': 'application/json',
},
});
axiosClient.interceptors.request.use(
(config) => {
const token = localStorage.getItem(STORAGE_KEY.ACCESS_TOKEN);
const configCopy = { ...config };
if (token) configCopy.headers.Authorization = `Bearer ${token}`;
else throw new Error('token이 없습니다.');
return configCopy;
},
(error) => Promise.reject(error)
);
클라이언트 인스턴스가 이렇게 생겼습니다.
나중에 생각난 것이지만 만약에 node 서버에서 storage접근을 차단했으면 여기서부터 에러가 발생했어야 합니다.
시도: 검색 - 로그인 mocking - 하드 코딩
검색
How to mock data response using msw and axios.create() instance
저랑 비슷한 고민을 하는 사람을 발견했습니다.
Acquiring access token crashes test.
위에 MSW에 질문한 사람도 저랑 비슷한 고민을 한 것 같습니다.
axios랑 많이 사용하는데 예시를 공식 문서에 추가하는 것도 좋아 보입니다.
로그인 mocking
describe('Card Clint', () => {
beforeAll(async () => {
await signInAPI({
email: 'username@email.com',
password: '12345678',
});
});
afterAll(() => {
localStorage.clear();
});
});
로그인 요청을 하면 응답을 받자마다 interceptor가 토큰을 저장할 것이라는 생각이 들었습니다.
하지만 더 생각해보면 그냥 직접 심으면 되겠다는 생각이 들었습니다.
해결: 테스트 환경도 그냥 localStorage.setItem
describe('Card Clint', () => {
beforeAll(() => {
localStorage.setItem(STORAGE_KEY.ACCESS_TOKEN, 'token');
});
afterAll(() => {
localStorage.clear();
});
it('should create a card', async () => {
const newCard = {
question: '',
answer: '',
submitDate: new Date(),
stackCount: 0,
};
const res = await createCardsAPI(newCard);
expect(res).toBe('1234asdf');
});
});
모의로 토큰을 심었습니다. 그러면 토큰의 존재를 확인하고 요청을 차단하지 않습니다.
이렇게 생각해보면 또 취약점입니다. 테스트 케이스로 확장해야 하는 요구사항이 생각나다니...