로그인을 위한 쿠키가 저장이 안되서 로그인이 풀려버림.
프론트서버에서 로그인 테스트를 하는 중, 쿠키가 저장이 안되서 로그인이 계속 풀려버리는 문제를 발견했다.
크롬 개발자 도구를 켜서 보니 분명 백엔드서버에서 jsessionID를 구운 쿠키를 보냈고, 쿠키가 왔다는 것까지 보이지만, 저장이 되지 않고 있었다.
크롬 브라우저의 보안 정책 업데이트 - SameSite 이슈
알고보니, 크롬이 2020년 8월부터 쿠키에 SameSite 값이 별도로 지정되어 있지 않으면, 알아서 SameSite의 값을 Lax로 지정하기 때문에 발생하는 문제였다.
쿠키의 설정이 SameSite=Lax이면, 쿠키를 보내는 곳과 받는곳이 같은 도메인인 경우에만 쿠키가 저장된다.
즉, 쿠키가 저장이 안됬던 이유는
- 1) 백엔드서버에서 쿠키를 보낼때 SameSite 관련 설정을 별도로 해주지 않았다.
- 2) 백엔드서버와 프론트서버의 도메인이 달랐다. (백엔드서버는 ec2에서 띄운다음에 가비아에서 도메인을 사서 붙여 쓰고 있었고, 프론트서버는 S3에 띄워서 아마존 기본 s3 도메인을 쓰고 있었다.)
그래서 크롬에서 알아서 도메인이 서로 다르므로 우리가 보낸 쿠키를 SameSite=Lax로 지정해버려서 쿠키가 저장이 되지 않고 있었다.
백엔드서버와 프론트서버의 도메인을 맞춰주자.
이 SameSite문제를 해결하는 방법은 크게 두가지가 있을 것이다.
- 1) 백엔드서버에서 쿠키를 보낼때 SameSite 설정을 별도로 None으로 지정해서 보내준다.
- 2) 백엔드서버와 프론트서버의 도메인을 같게 맞춰준다.
우리는 처음에는 두 번째 방법을 택해서 해결했다.
현재 백엔드는 가비아에서 도메인을 사서 dev-api.gist-petition.com이라는 도메인을 사용하고 있었다.
그래서 프론트서버의 도메인을 s3 버킷의 도메인을 그대로 쓰지않고, s3 버킷을 cloudfront에 붙여서 도메인을 dev.gist-petition.com으로 등록하였다. (sameSite는 서브도메인이 같으면 같은 사이트로 인식한다.)
이 때,cloudfront는 https 프로토콜로 연결되기 때문에, https로 프론트엔드와 백엔드의 프로토콜도 같이 맞춰주었다.
