[Imgenie] https와 쿠키를 도입했음

이미지니 서비스 개발은 거의 막을 내렸지만 어쨌거나 나에겐 해야할 것이 있었다.

별로 대단한 것은 아니지만, 아침 스터디에 도언니의 "그래도 한번 올려보는게 어때?"라는 말을 듣고 글을 써본다.

이번글은 개발에 있어서 유용한 정보를 제공하는게 아니거나와 내용도 사실 별로 없다는 것을 유의해주셨으면 좋겠다.

 

이번 글은 그저 끄적임의 연속

 

🍪 쿠키 도입

기존에는 jwt로 사용자 인증을 담당했었다. 요청헤더에 토큰이 없으면 재발행 하게했다.

그런데 jwt는 보통 사용자 인증을 안전하게 구현하기 위해 쓰이는데, 우리 서비스에는 이렇게 까지 할 필요가 없었다.

쿠키를 도입하면 헤더에 넣지 않아도 자동으로 전송되고 더 일반적인 방법인 것처럼 보였다.

다른 개발자분의 의견도 쿠키를 도입하는 계기가 되었다.

음료는 없어~ 목 막혀도~

사실 프로그래머가 아니더라도 어릴때부터 엄마 눈치를 보며 컴퓨터를 열심히 했던 친구들은 대부분 토큰보다 쿠키에 친숙할 것이다.

나도 그랬고, 스터디를 통해서 쿠키의 원리도 알았으니 더욱 그랬다.

그래서 금방 교체할 수 있을줄 알았다.

하지만..

 

🛡️ 쿠키 보안정책은 황금방패

혹시 중국의 인터넷 검열 시스템인 황금방패를 아는지 모르겠다.

쿠키를 도입하면서 크롬의 쿠키 보안정책은 마치 황금방패처럼 느껴졌다.

 

이것저것 해보면서 모든 이슈를 다 만난 것 같은 느낌이 드는데 이슈를 나열해보자면 아래와 같다.

1. Cross Origin Rescource Sharing(CORS)가 제대로 명시되어 있지 않은 경우 쿠키를 거부함
   (와일드카드 * 로 되어있었기 때문에 거부당했다) -> 여기에 프론트 서버의 도메인을 명시함
2. 쿠키 옵션 samesite=none이면 secure 옵션이 필수적이다.
   -> lax로 바꿈 (fastapi에선 아무것도 주지않으면 lax로 고정되고, 아무 옵션이 없다면 크롬도 lax로 인식한다)
3. 쿠키 옵션 samesite=lax이면서 다른 도메인의 쿠키를 저장하려면 secure 옵션이 필수적이다.
   -> secure 옵션 활성화
4. secure옵션을 활성화 했지만 http로 전송된 쿠키는 거부함
   -> cloudflare의 무료 ssl서비스 이용 (그렇게 안전하지 않다고 한다)

우리의 개발서버는 도메인 네임이 없고, ip를 그대로 이용하지 않았기 때문에 어떤 방법을 써도 소용이 없었다.

게다가 개발서버까지 ssl을 도입하고 싶지 않았다.

 

⚙️ 서브폴더 활용과 로드밸런서

항복이다 이것들아

결국 크롬의 노력을 인정하고 프론트와 백의 도메인을 통일하는 쪽으로 방향을 트게 된다.

서브폴더를 활용해 둘을 구분하도록 했다.

기존 imgenie.co는 프론트엔드로 요청이 전송되고 imgenie.co/api는 백엔드로 요청이 전송될 것이다.

개발서버는 서브도메인을 파서 나누었다. 개발 프론트는 dev.imgenie.co, 백은 dev.imgenie.co/api이 된다.

 

개발서버에선 react의 setupProxy.js를 이용해 /api로 전송된 요청은 백엔드ip로 재작성하게 했지만, 배포서버에선 이렇게 할 수 없었다.

그래서 gcp의 로드밸런서를 활용해 /api와 /api/*는 백엔드 서버로 라우팅하게 했다. (gcp서비스는 아주 잘되어 있었다. 돈도 별로 안들고 좋다)

 

👏 마무리

이 글을 쓰기 전에 "90%에서 중단하는 것"이라는 글을 보았다.

이번에는 프로젝트가 막 끝났지만, 그래도 시간을 투자한 보람이 있다.

https를 무료로 도입하는데 성공했고 서비스가 더 멋져진 것 같다.