토스페이먼츠 PG 결제 시스템을 프로젝트에 적용하기 위해 '예매 확정 API'에 대한 프론트 페이지를 만들고 테스트해보았다.
정말 오랜만에 만나는 CORS 에러...
예전에 CORS에 대해서 알아보고 해결했던 적은 있는데
https://velog.io/@lswoo0705/CORS
이 때는 MSA가 뭔지도 몰랐을 시절
저 때의 방법으로도 여전히 CORS 에러가 발생했다.
우선 CORS(Cross-Origin Resource Sharing)에 대해서 다시 한번 자세히 알아보기로 했다.
CORS 에러는 브라우저 보안상의 이유로 스크립트가 자신의 출처가 아닌 다른 출처의 리소스에 접근하는 것을 금지하기에 발생하게된다.
Origin의 개념에 대해 알아보자면
웹에서 Origin은 프로토콜, 주소, 포트번호의 튜플로 구분된다.
Origin = [프로토콜]://[Host의 IP 주소 또는 URL]:[포트번호]
여기서 포트번호는 생략이 가능한데 HTTP면 80, HTTPS이면 443이 생략되어있는 것이다.
출처(Origin)가 다르다는 것은 프로토콜, URL, 포트번호가 모두 다르다는 것을 의미한다.
프로토콜(HTTP, HTTPS, ...)
URL(asdf.com, qwer.co.kr, ...)
포트번호(80, 433, 8080, ...)
내 프론트 페이지는 포트번호가 63342로 되어있었는데
localhost:63342는 주로 로컬 개발 환경에서 IDE(JetBrains의 WebStorm, IntelliJ 등)가 사용하는 기본 포트이다.
즉, 클라이언트가 localhost:63342에서 실행되고, 서버가 localhost:12011에서 실행되고 있어 CORS 정책으로 인해 요청이 차단되고 있기 때문에 발생한 에러이다.
기본적으로 서로 다른 출처들 간의 요청은 차단되기 때문에 다양한 데이터들의 공유가 발생하는 웹 생태계에서 악성 사이트등에 접속할 경우 개인정보가 유출될 위험이 있는데,
이 때문에 CORS는 특정 기준을 충족하는 경우에만 리소스를 공유할 수 있도록 허용하는 방법이 존재하는 것이고, 나와같은 개발자들은 이 허용 방법에 대해서 반드시 알아야 이런 에러를 또 마주치는 일이 없게되는 것이다.
내가 신뢰할 수 있다고 생각하는 특정 사이트들에 대해서 다른 Origin이더라도 허용하도록 서버가 응답하는 시점에 알려주면되는데
Simple Request인 경우
이 경우에는 브라우저가 받은 요청이 어떤 Origin에서 시작됐는지 헤더를 추가한다.
서버는 받은 CORS 요청이 유효한지 아닌지 Access-Control-Allow-Origin 헤더로 응답해준다.
Preflight Request인 경우
Preflight Request(OPTIONS Method)는 브라우저가 특정 조건을 충족하는 요청을 보내기 전에 서버가 요청을 허용하는지 확인하기 위해 사용된다.
위에 발생한 CORS 에러 상황에서 Network의 요청 Header를 확인해보면
OPTIONS Method가 실패한 것으로 보아 Preflight에서 실패한 것을 확인된다.
이번에는 헤더가 같은 출처를 두 번 이상 포함하고 있어, 브라우저가 이를 허용하지 않는다는 에러가 발생
앞에서 했던 설정들 중 application.yml 파일을 제외하고 설정들을 주석처리 해봤다.
진짜 성공!
DB에서 실제로 결제가 생성되기도 했다.
근데... 결제창으로 넘어가지지가 않는다.
이거는 다음 포스팅으로