문제 상황
로컬
로컬 환경은 CORS처리가 이미 완료되어 있고, 프론트 3000포트와 백 5005 포트가 통신이 잘 된다. 언제나 그렇듯, 로컬 환경은 잘 되기 마련이다.
JWT + OAuth를 활용하여 인증 / 인가를 구현한 상황이었고, JWT 관련 토큰들은 "쿠키" 형태로 저장되고 있었다.
CloudFront
하지만 역시나 AWS 배포 후에는 문제가 터지고 말았다.
바로 "JWT 토큰이 쿠키로 발급되더라도, 새로 고침하면 해당 쿠키가 다 사라진다는 것이다."
문제점 분석
절차 (프론트엔드)
- 웹 브라우저 개발자 도구를 연다.
- 응용 프로그램 탭으로 이동한다.
- 저장소 - 쿠키 탭으로 이동한다.
절차 (백엔드)
- JWT 라이브러리 코드에 디버그 중단점을 건다.
- 여러 가지 시나리오를 걸며 로컬에서 재현한다. (ex : api 호출 직전에 csrf token을 제거한다던지 등)
분석
삽질이 조금 걸렸지만, 생략하고 원인부터 바로 말하겠다.
쿠키의 도메인과 속성이 문제였다.
이걸 알게 된 건 다음 이유였다.
1. 로컬에선 백엔드에서 보낸 JWT 쿠키와 프론트엔드 브라우저에 담긴 도메인이 localhost로 모두 같다.
2. 클라우드 프론트에서 Google Analytics 쿠키는 살아 있는데, 백엔드에서 보낸 쿠키는 사라진다.
2.를 조금 더 자세히 설명하자면,
Google Analytics 쿠키의 도메인은 S3의 도메인인데, 백엔드의 도메인은 EC2 도메인 이름이였다.
해결
절차
- 문제점 분석에서 보았듯이, 쿠키 도메인이 다른 것을 관찰하였다.
- 쿠키 도메인 속성과 관련된 문제를 ChatGPT 4.0에게 질의하여 힌트를 얻었다.
- 해당 문제 중, Cross-Domain Cookies 라는 것을 알게 되고, 해당 키워드로 구글에 검색했다.
결론
백엔드 (Flask)에서 SameSite = None, 쿠키 도메인을 프론트엔드 도메인(S3 도메인)으로 지정하였더니 해결되었다.
개발자 도구로 확인해보면, 백엔드에서 보낸 쿠키 도메인이 프론트엔드 도메인으로 바뀐 것을 확인할 수 있다.
그래도 안될 경우
여기까지 했는데, 안된다면 다시 개발자 도구를 살펴보자.
자세히는 모르지만, 클라우드 프론트는 쿠키 역시 캐싱을 하는 것 같다. 이 상태인 경우, "csrf double submit dose not match" 라는 에러가 발생한다.
이 때에는 백엔드 도메인으로 되어 있는 쿠키가 남아있는 것이므로, 해당 쿠키를 다 지우고 다시 실행해보라. 그러면 될 것이다.
느낀 점
플라스크 그만 쓰고 싶다. 프레임워크 자체가 너무 단순하다보니, 프로그램이 무거워질수록 개발하는 사람이 신경쓰거나 직접 구현해야 할게 많아진다.
플라스크는 프로토타입에나 쓰는 게 맞을 듯.
참고 링크
https://velog.io/@code-bebop/CORS%EC%9D%98-Cookie
