클라이언트 측 코드를 나름 만족스럽게 짜놨다고 생각했는데 막상 서버로 통신하려고 하니 내 발목을 부여잡고 이틀 동안 안놔주던 물귀신 같은 존재가 나타났다.
그거슨 바로.. CORS 에뤌...

👻👻👻👻👻👻👻👻👻👻👻👻👻👻👻👻👻👻👻👻👻👻👻👻👻👻👻👻👻👻👻👻👻👻
👻👻👻👻👻👻👻👻👻👻👻👻👻👻👻👻👻👻👻👻👻👻👻👻👻👻👻👻👻👻👻👻👻👻

나름 프로젝트 들어가기 전부터 proxy는 근본적 원인 해결이 아니기 때문에 원인을 제대로 파악하여 cors option으로 정석적으로 처리해야 한다고 생각했다. 어떤 상황에서 CORS에러가 뜨더라도 미리 제대로 알고 있다면 해결할 수 있다고 믿었고, 이러한 믿음 덕분에 악명 높은 CORS 에러에 대해 제대로 공부했다고 생각했다.

[WEB 개발 기초] CORS 에러와 해결 방법에 대해 알아보자.
https://velog.io/@jasmine0714/WEB-%EA%B0%9C%EB%B0%9C-%EA%B8%B0%EC%B4%88-CORS-%EC%97%90%EB%9F%AC%EA%B0%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EC%A7%80-%EA%B7%B8%EB%A6%AC%EA%B3%A0-%ED%95%B4%EA%B2%B0%EB%B0%A9%EB%B2%95%EC%9D%84-%EC%95%8C%EC%95%84%EB%B3%B4%EC%9E%90
이렇게 열심히 공부했었다.

그런데,, 막상 로그인을 구현하며 CORS 에러를 3번을 만났는데 점점 더 해결이 어려워졌고 특히 3번째 에러는 꿈인가 싶을 정도로 24시간 넘게 원인 파악이 안됐다.

내가 만난 CORS 에러들을 소개하겠다.

step1. POST 요청 CORS 에러

-> Access-Control-Allowed-Origin에 url 명시하여 간단히 해결

두근두근 처음으로 서버에 POST 요청을 보냈는데!

음~ 난 이런 걸로 당황하지 않g~ 나는 CORS 에러를 공부한 솨람~

백엔드 개발자 준기님께

액쇄스컨츄롤얼라우드오리쥔 http://localhost:5173으로 설정해주실 수 있나요오?

뚝딱 바로 해결.
이게 CORS 에러지~ 역시 공부해놓길 잘했어 후후

준기님께 displayName, email, password를 보내고 XHR finished loading: POST 라는 문구를 보게 되었다. 해결 성공!

(참고로 사진의 console 창에 displayName도 있고 name도 있는데 이건 다른 버그다. CORS 에러 해결 후 name만 남기고 displayName은 지웠다.)

POST 요청 응답으로 돌아와야 할 access token이 처음에 브라우저 콘솔창에 안 찍혔었는데,

서버 측에서 exposedHeaders에 Authorization을 설정해주셔서 access token도 접근이 가능해졌다.

POST 요청 성공!

step2. Get 요청 CORS 에러

POST 요청까지는 나름 간단히 해결을 했는데, 이제 access token을 받고 get 요청을 하려고 하니 또 CORS 에러가 났다.

않이 적이요; POST 요청을 성공했는데 GET 요청을 하면 CORS 에러가 난다는 게 도대체 뭐지? postman으로는 데이터가 잘 받아와졌고, CORS 에러가 원인인 건 확실했다.

준기님과 더 이상 CORS 에러 때문에 진행이 어려워져서 1시간 동안 머리 싸매고 사경을 헤매다가 작업을 중단했다. 그리고 하루종일 열심히 해결 방안을 찾아보았다.

작업 중단 당시 준기님의 CORS 설정은 이러했다.

시도 1. Allowed-method에 OPTIONS를 추가하면 되지 않을까?

나의 추리 과정

준기님이 허용 메서드에 GET, PATCH, DELETE, POST를 추가했다고 하셨지만 OPTIONS를 추가했다고 하신 적은 없다. 그럼 허용 메서드에 hoxy OPTIONS를 추가하면 될까?
그래 바로 그걸거야! 처음에 성공했던 POST 요청은 예비 요청이 필요없는 단순 요청이어서 OPTIONS 없이도 성공한걸까..? (근데 POST 요청 때도 ContentType: application/json이었는데 그럼 단순 요청 허용 조건을 만족하지 못할 것 같은데? 왜 됐지? 이 의문은 아직도 풀리지 않음) 이번에 하는 GET 요청에는 header에 authorization이 들어있어서 단순 요청이 아니어서 예비 요청이 필요했던 것 아닐까?!유레카!!!!

그렇게 준기님께 얘기를 드리고 OPTIONS를 추가해봤는데 아주 재미있게도 예비 요청만 성공했다. ㅋㅋㅋㅋㅋㅋㅋ
네트워크 탭에 보니 예비요청만 성공한 걸 확인할 수 있었다. 본 요청인 GET요청은 여전히 fail.

다음 날 아침에 전체 회의 때 집단 지성 활용을 위해 문제를 공유해봤지만, 답이 나오지 않았다.

컴퓨터는 정직하고 뜻대로 안되면 개발자 잘못이라 했는데 진짜 아무리 생각해보고 코드를 뜯어보고 검색을 해봐도 24시간 넘게 답이 나오지 않았다. 서버 측에서도 Access-Control-Allowed-Origin

시도2. 헤더에 'ngrok-skip-browser-warning': 'true' 추가 (개발 단계에서 임시 우회 방법)

점심도 못 먹고 CORS 에러 해결해보겠다고 붙잡고 있는데, 준기님이 내가 상주하고 있던 디스코드 회의실로 호다닥 달려오셔서 이 방법을 찾아와 알려주셨다.

ㅎㅎ...? 우리는 개발 단계에서 로컬 서버 테스트를 위해 ngrock을 사용하고 있었다. 테스트 URL도 ngrock url을 받았는데, 개발 단계에서 ngrock url로 get 요청을 보낼 때에는 'ngrok-skip-browser-warning': 'true'를 추가해야 한다고 한다. ngrock url로 테스트할 때 개발 단계에서 임시로 우회하는 방법이고, 서버 배포가 끝나면 'ngrok-skip-browser-warning': 'true'을 url을 배포 url로 교체하고 저 필드를 제거하면 된다고 한다. 물론 지금까지 서버 측에서 할 수 있는 CORS 설정이란 CORS 설정은 다 끝낸 뒤이기 때문에 가능한 것이다.

바로 팀 디스코드에 공지.

결국 장장 48시간만에 CORS 에러를 해치우고 다시 개발에 집중할 수 있게 되었다. 아주 강력한 CORS 신고식이었군. 그럼 짜이찌앤~