TIL-221006- 인터셉터의 역할

어제는 테스트때문에 거의 하루종일 시간을 써버려서 진도를 못나가서 오늘은 진로를 조금 바꿨다. 일단 MVP를 만들고 테스트 코드를 통해서 디테일을 챙기자? 라는 식으로 진행을 했다. 테스트를 잘 짤 수있으면 이렇게 할 필요가 없지만 리액트쪽은 테스트를 짜는 것 자체가 어려워서 일단은 완성을 시키고 보완을 해 나갈 려 한다.  그리고 다음 주 에는 예비군 훈련도 있어 사실상 하루를 빠져야 하기 때문에 이번 주말 까지는 MVP를 완성 시켜야 한다.

 

오늘은 interceptor라는 것에 대해서 조금 더 알게 된 것 같다. 기존에 유저가 가지고 있던 잔액이 새로고침을 하면 계속 0원으로 바껴버리는 이슈가 있었는데 잔액을 로컬 스토리지에 저장을 하고 그 저장한 값을 쓰는 식으로 하고 있었다. 그런데 이렇게 잔액을 로컬 스토리지에 저장하는 게 맞나?? 잔액은 꽤나 민감한 정보이다. 로컬 스토리지에 저장을 해버리면 클라이언트에서 로컬 스토리지의 값을 변경해 버리면 

 

돈 복사 버그가 일어나기 때문에 이건 아니라고 결정을 내렸다. 결국 서버에서 유저에 대한 정보를 들고 와야 한다 라는 게 결론이였다.

그래서 저번 주 코드를 조금 살펴보니 fetchAccount라는 함수가 있었다. 서버에서 로그인한 해당 유저에 대한 정보를 들고 오는 

 

함수인데 그렇지 이게 필요한 것 이였다. 그렇다면 해당 유저에 대한 정보를 어떻게 찾을 것인가? 바로 accessToken을 이용해서 찾을 수가 있다. 현재 아이디를 인코딩 해서 나오는 값이 accessToken이기 때문에 이 accessToken을 HTTP header에 있는 Authorization에 붙여서 백엔드로 보낸다.

 

하지만 컨트롤러에서는 헤더에 보낸 accessToken을 처리 하지 않는다. 컨트롤러는 accessToken이 decode된 값을 가지고 서비스로직을 수행해야 한다. 이렇게 해주기 위해서 바로 interceptor라는 것을 이용한다. interceptor중에서도 prehandler를 사용하는 데 

 

prehandler는 컨트롤러의 로직이 실행되기 전에 먼저 실행이 된다. 그러면 지금 해야할 것은 accessToken을 decode해준 값(아이디)를 설정해 주어야 한다. 말 그대로 interceptor였다. 컨트롤러의 로직이 시행되기 전에 header에 있는 Authorization을 가로채서 아이디로 바꿔 준다. 

 

 

오늘까지 일단 MVP완성을 목표로 하자