CORS - AWS편

이 포스팅은 CORS 주제를 바탕으로 연속으로 포스팅되었습니다.

[FrontEnd] - CORS - 개념편

CORS - 개념편

 

---

 

AWS의 API Gateway에서 CORS를 적용하는 것을 은근히 어려워하시는 분들이 많다. 이는 코드에서 헤더를 잘못 추가했는지, API Gateway에서 설정을 잘 못했는지를 정확히 구분하기 힘들기 때문에 어디서부터 어디까지 봐야 하는지 막막해서 그런 것 같다.

나 또한 마찬가지였고, 이제는 그것을 구분할 수 있게 되면서부터 적용하는 데에 있어 두려움이 없어졌다. 글을 읽으시는 분들도 마찬가지로 이 글을 읽고 난 후에는 자신감 있게 CORS를 적용할 수 있게 되었으면 좋겠다.

자. 그러면 이제부터 AWS APIGateway에서 CORS를 적용하는 방법에 대해서 알아보자.

이 글은 AWS API Gateway에서 기본적인 메서드를 생성하는 방법을 아는 것을 전제로 작성되었습니다.

 

---

 

 

AWS APIGateway 콘솔을 이용하여 적용할 경우

처음 적용 할 때에는 콘솔에서는 클릭 몇 번이면 알아서 적용이 되기 때문에 콘솔로 CORS를 적용하는 것을 추천한다.

메서드를 만든 후 해당 메서드를 클릭한 뒤 아래의 이미지의 순서대로 클릭해 보자.

 

왼쪽 이미지는 추가할 리소스 클릭 → 작업 클릭 → CORS 활성화 클릭의 순서로 클릭의 진행 순서이고, 순서대로 진행하면 오른쪽 이미지의 페이지가 나오게 된다. 여기서 별다른 설정 할 게 없다면 그냥 CORS 활성화 및 기존의 CORS 헤더 대체 버튼을 누르면 된다.

 

위의 작업이 정확히 어떤 것을 의미하는지 잘 모른다면 개념편을 다시 한번 읽어보자. 간략하게 설명을 하자면

1~4번 : Preflight를 위해서 OPTION이 필요하기 때문에 OPTIONS 메서드를 생성하고, 응답을 추가해 준다.

5~6번 : Preflight에서 허용할 Header, Method, Origin을 추가해 준다. AWS를 이용하면서 필요한 기본적인 것들은 보통 다 들어가있는데, 특수한 헤더를 추가 해야 될 경우 Access-Control-Allow-Headers에 추가 해 주면 된다.

7~8번 : 응답 헤더 추가

이제 “예, 기존 값을 대체하겠습니다.”를 누르게 되면 OPTIONS가 생성이 되며 CORS적용이 완료된다. 정말 간단하다.

이렇게 진행했음에도 잘 안된다면 아래의 그래도 안될 경우를 참고하자.

 

이제 API 배포를 한 후(배포하는 것을 잊어먹지 말자) 개념편에서의 Curl을 이용한 방법이나 Postman을 이용한 방법과 같이 200 OK가 나오는지 확인하면 된다.

정말 농담이 아니라 이렇게 하면 끝이다.

 

그래도 안될 경우

사실 이 블로그 포스팅은 이 주제를 이야기하기 위해 이렇게 끌고 왔다고 해도 과언이 아니다. 내가 겪은 케이스를 바탕으로 해결했던 경험에 대해서 소개하려고 한다.

 

첫 번째로 위와 같이 따라 했음에도 403만 덩그러니 나온다면 API 배포를 하지 않았을 확률이 매우 높다. access-control-allow-headers, access-control-allow-origin, access-control-allow-methods가 응답에 포함되어 있지 않다면 배포를 하지 않았거나, Reqeust 경로를 잘못 설정했을 가능성이 매우 높다.

Route53으로 사용자 지정 도메인을 지정하였을 경우 내가 잘 적용했는지 헷갈린다면 왼쪽 메뉴에서 스테이지를 누른 후 내가 생성한 스테이지에 들어가서 URL호출에 있는 경로로 요청을 보내보자!

 

두번째로 응답이 500이 나온다면 설정에서 이진 미디어 형식을 확인해 보자.

File upload를 위해서 몇몇 블로그를 참고하다가 이진 미디어 형식을 */*으로 지정하라는 글을 참고하고, 그 이후 CORS를 적용하려고 하였다.

그런데 이상하게 CORS가 적용이 되지 않아 Curl로 확인을 하였고, 응답이 500으로 받는 것을 확인했다.

 

원인을 파악하기 위해 스테이지 편집기에서 로그/추적에서 CloudWatch 로그 활성화를 해 준 후 동일한 동작을 반복하였다.

 

이제 CloudWatch의 로그 그룹에 자동으로 생성되어있는 나의 API Gateway의 로그를 확인 해 보면 다음과 같은 로그가 남겨져 있었다.

OPTIONS로 Request가 왔고, 응답 값은 500에 “Internal server error”로 되어있으며, 헤더는 CORS를 허용하는 헤더로 와있다. 하지만 헤더가 CORS를 허용하도록 오더라도, Preflight가 200이 아니라면 허용되지 않기 때문에 결국에는 브라우저에서 에러를 띄웠다.

혹시 해당 에러가 왜 발생했는지 확인할 수 있는 방법이 있다면 댓글로 남겨주세요!

 

이때 당시 File Upload를 구현한 지 시간이 어느 정도 지났기 때문에 나는 단지 Internal server error라는 하나의 단서에 원인을 해결했어야 했다.

원인을 해결하기 위해 CORS가 설정되어있는 다른 메서드에도 OPTIONS를 날려 본 결과 같은 결괏값을 볼 수 있었고, 메서드에 걸려있는 CORS는 문제가 없다는 생각을 하였다.

그래서 설정을 참고하기 시작했고, 이진 미디어 형식이 걸려있어 우선 이를 지우고 OPTIONS를 보내보니 정상적인 응답이 오기 시작했다.

만약에 내가 OPTIONS를 보낼 줄 모르는 상황이었다면 웹의 코드부터 해서 다 뜯어보다가 많은 시간을 낭비했을 것 같다.

(물론 이진 미디어 형식이 범인인 것을 알게 되는 데에는 많은 시간이 소요되었다.)