지난 3개월간 처음 마주한 스택들을 습득하고 나름 열심히 공부했다고 생각했습니다. 하지만, 첫번째 프로젝트를 시작한지 5일차를 지나며 이것 하나를 분명하게 알게되었죠.
헛 공부했구나!
지난 3개월간 빈칸에 필요한 코드를 작성하며 흐름을 파악하기 바빴으나,
프로젝트는 아무것도 없는 상태에서 하나씩 쌓아가야 한다는 현실에 매 순간이 도전의 연속이었습니다.
1. axios.defaults.withCredentials = true;
상황
1. 회원가입에 필요한 모든 유저 정보를 입력 완료
2. 유저 정보를 axios.post("/signup", userInfo)로 요청을 보냄
3. 서버에서 req.user 값이 undefined로 나온 상황
4. 정상적으로 통신했다면, req.user 객체에 정보가 담겨있어야 함
왜 이런 상황이 발생했는지 알기 위해,
"axios"로 구글링 해봤습니다.
링크 :https://inpa.tistory.com/entry/AXIOS-%F0%9F%93%9A-%EC%84%A4%EC%B9%98-%EC%82%AC%EC%9A%A9
aixos의 정의와 특징을 다시 정리했습니다.
aixos, 왜 쓰는걸까?
간단하게, 백엔드와 프론트엔드가 통신을 쉽게하기 위해 사용하는 비동기 통신 라이브러리 입니다.
그럼, 어떻게 쉽게 통신하게 하는 걸까요?
HTTP 요청과 응답을 하기 위해선 JSON형태로 변경하여 통신해야 합니다.
이미 JS에 fetch api가 있어 백엔드와 프론트엔드의 통신이 이루어지고 있었지만, 매번 통신 할때마다 JSON 형태로 데이터를 수정해야 하는 단점이 있었죠.
axios는 이런 fetch api의 단점을 보완했습니다.
HTTP 요청과 응답을 JSON형태로 자동으로 변경해주기 때문이죠.
클라이언트 - 서버 간 통신 방법
다시 두번째 상황으로 가보겠습니다. 클라이언트에서 작성된 유저 정보를 서버로 axios.post로 요청을 보낼 때, 출처가 서로 같았는지 확인을 하지 않았음을 알았습니다.
출처(origin)란, 서버의 위치를 의미하는 URL이며, protocol,host,port까지를 의미합니다.
그렇다면, 제가 작업한 클라이언트의 origin과 서버의 origin은 같았을 까요?
달랐습니다.
웹 통신 정책에는 SOP(same origin policy)와 CORS(Cross Origin Resurce Sharing) 두가지 정책이 있습니다.
SOP은 동일한 출저에서만 리소스 공유가 가능한 정책입니다.
따라서 이번 에러의 원인은 클라이언트와 서버 같 origin이 달랐기 때문에, SOP 정책 위반에 따른 문제였습니다.
이를 해결하는 방법은 굳이 동일한 origin을 설정하지 않아도 되는 CORS 정책으로 해결될 수 있었습니다.
axios 요청 파라미터 옵션 : withCredentials의 기본값인 fals를 true로 변경!
axios 요청 파라미터 옵션인 withCredentials의 기본값은 fals로 설정되어 CORS 요청을 허용하지 않게 설정되어 있습니다.
withCredentials의 기본값을 fals에서 ture로 변경하면,
CORS 요청을 허용하게되고, 쿠키값을 전달 할 수 있게 되는 것이죠.
회원가입 페이지에는 axios 요청이 자주 요구되므로,
withCredentials의 기본값을 전역으로 설정하여 편의성을 확보 할 수 있었습니다.
