개발 중 제일 막막하고 많이 마주쳤던 문제는 cors 였던 것 같다.
cors 문제가 발생했던 상황별로 정리하고자 한다.
개발 초반부 컨트롤러의 클래스 레벨에 CrossOrigin에서의 요청을 허용하기 위해 @CrossOrigin을 붙여 놓았었다.
그리고 Spring Security에서 별도의 cors 설정을 적용하였다.
이 경우 즉 @CrossOrigin 어노테이션과 cors 설정에서 allowedOrigins을 함께 사용시 충돌이 발생해 CORS 문제가 발생했던 것 같다. 참고
컨트롤러의 @CrossOrigin 어노테이션을 제거해 해결하였다..
로그인 인증 성공 시 응답 헤더에 JWT 토큰을 발행하여 클라이언트측에서 이후 요청마다 헤더에 토큰값을 넣어 요청하는 식으로 구현하였다.
헤더에 토큰을 넣어 응답하는 부분까진 확인하였는데 프론트측에서 헤더의 토큰값이 네트워크 쪽에는 뜨지만 콘솔로 받아와 이후 요청에 사용할 수 없다고 했다.
이런 경우 cors 설정에 exposeHeaders()를 통해 토큰에 관련된 헤더를 추가 해야한다고 한다.
setExposedHeaders()를 통해 인증 성공시 헤더에 추가한 "Authorization"과 "Refresh" 헤더명을 추가하였다.
그리고 인증 크레덴셜 값을 사용할 수 있게 해주는 setAllowCredentials(true)를 추가하였다.
그런데도 여전히 CORS 문제가 발생하였다..
그렇게 한참 헤매다 알아낸 사실
setAllowCredentials(true)로 크레덴셜 값을 사용할 수 있게 설정하면 AllowedOrigins에 "*" 애스터리스크를 사용할 수 없다고 한다...!
백엔드 서버의 경우 AWS EC2를 통해 http로 배포하였고 프론트엔드의 경우 깃허브를 통해 배포하였다.
깃허브로 배포하고 Https 프로토콜이었고 백엔드 API는 Http 프로토콜이었다.
cors 설정에 배포된 https 프로토콜의 url을 추가하지 않았을때 프론트측에서 https에서 http api를 호출 할 수 없다는 에러를 받았다고 한다.
그래서 혹시나 allowedOrigin에 https url을 추가하였더니 이젠 cors 에러가 발생했다.
이 경우 양쪽다 https나 http로 프로토콜을 통일해야 하는 것 같아 백엔드 api를 https로 변경하려 했다.
https 인증서를 발급받기 위해서 도메인을 구입해야하는 것 같아 배포기한까지 시간도 얼마 안남아
결국 프론트 배포를 깃허브가 아닌 AWS S3로 배포해 http로 통일하기로 했다..
클라이언트 서버를 S3로 배포 한 뒤 백엔드 로컬에서 AllowedOrigin에 배포 url을 추가하고
ngrok을 이용해 터널을 열어 테스트를 해보았다.
이번엔 POST 요청을 제외한 다른 요청들에서 CORS 문제가 발생했다..
여기서도 한참 헤맸는데 프론트 팀원 한분이 S3 -> EC2 요청 시엔 문제없이 동작하는 걸 찾아내셨고 우선 문제 없이 배포하는데 성공하였다...
S3 -> ngrok으로 연 로컬 백엔드 API 접근 시 왜 에러가 발생하는지 아직 잘 모르겠다..
해당 부분은 좀 더 찾아봐야 할 것 같다.
https://github.com/Jung-seo/seb45_pre_009
http://preproject.s3-website.ap-northeast-2.amazonaws.com/