Cross Domain 간 쿠키 전송

Cross Domain 간 쿠키 전송

서론

• 현재 인증 인가 시스템이 세션 방식으로 구성되어 있다.

• 세션은 서로 같은 도메인 혹은 서브도메인에서 호스팅되어야지만 공유가 가능하다.

• prod 서버는 프론트엔드와 백엔드의 도메인이 서브 도메인 관계라 세션 공유에 문제가 없었다.

• 허나, dev 서버의 경우 백엔드만 사용하고 프론트엔드는 local에서 실행시키고 있어 세션 공유를 하지 못하는 문제가 있었다.

• 이로 인해 백엔드 실행 파일을 프론트엔드에 넘겨주어 프론트 측에서 백엔드를 직접 local에서 함께 실행 시켜 개발을 진행하고 있다는 큰 불편함이 존재했다. 용량이 큰 jar 파일을 매번 직접 넘겨줘야 했기에 병목이 불가피했다.

• 이 고질적인 문제를 해결하기 위해 인증 인가 시스템을 토큰 방식으로 전환할까도 고민했지만

• 일단 더 빠르게 적용할 수 있는 방법을 찾았다.

• 쿠키 설정을 통해 서로 다른 도메인 간에도 전송 가능하게 해주는 것이다.

본론

• 포스트맨은 도메인을 직접 추가해서 쿠키 설정을 해줄 수 있다..
Using cookies | Postman Learning Center
Using cookies: documentation for Postman, the collaboration platform for API development. Create better APIs—faster.

https://learning.postman.com/docs/sending-requests/cookies/

• 그렇다면, 프론트가 local에서 실행할 땐 어떻게 해야 다른 도메인의 쿠키를 받을 수 있을까?
• 가장 간단한 방법으론 응답 header에 쿠키를 담아 보내는 방법이 있겠지만, 나는 설정을 통해 근본적인 문제를 해결하고자 했다.
• 따라서 SameSite 설정을 none으로 바꿔주어 이를 해결했다.
• 다만, SameSite 설정을 none으로 하려면 secure 설정이 true여야 해서 https 배포를 함께 진행해줬다.
• 참고로, SameSite의 default값은 2020년부터 lex로 바뀌었다고 한다.
새로운 SameSite=None; Secure 쿠키 설정에 대비  |  Google 검색 센터 블로그  |  Google for Developers
2020년 1월 16일 목요일

https://developers.google.com/search/blog/2020/01/get-ready-for-new-samesitenone-secure?hl=ko

• cookie 속성에 대해선 아래 문서를 참고했다.
Set-Cookie - HTTP | MDN
The Set-Cookie HTTP response header is used to send a cookie from the server to the user agent, so that the user agent can send it back to the server later. To send multiple cookies, multiple Set-Cookie headers should be sent in the same response.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie#samesitesamesite-value


Lax Cookies are not sent on normal cross-site subrequests (for example to load images or frames into a third party site), but are sent when a user is navigating to the origin site (i.e., when following a link). This is the default cookie value if SameSite has not been explicitly specified in recent browser versions (see the "SameSite: Defaults to Lax" feature in the Browser Compatibility). None Cookies will be sent in all contexts, i.e. in responses to both first-party and cross-origin requests. If SameSite=None is set, the cookie Secure attribute must also be set (or the cookie will be blocked). Secure A Secure cookie is only sent to the server with an encrypted request over the HTTPS protocol. Note that insecure sites (http:) can't set cookies with the Secure directive.

참고

다른 도메인간 쿠키 전송하기(withCredentials, credentials, sameSite, secure)

백엔드와 프론트엔드의 도메인 주소가 다른 경우가 많습니다. 이는 localhost인 경우에도 마찬가지입니다. 포트가 다르면 다른 주소로 칩니다. 이들간에는 쿠키 전송이 되지 않으므로 로그인이 유지되지 않아서 당황하시는 경우가 많습니다. 특히 개발자도구 Network 탭

https://velog.io/@wiostz98kr/다른-도메인간-쿠키-전송하기

Spring Session과 SameSite

배경 프로젝트를 진행하다보면 여러가지 문제를 만난다. 그 중 비교적 쉽게 해결하는 문제가 있는 반면 상당히 오랜 시간을 들여 해결하는 문제가 있다. 재밌는 건 아무리 어려운 문제여도 문제를 정확하게 정의하고 원인을 파악한다면 해결하는 건 쉽다는 점이다. 중요한 건 지금 일어난 문제가 어떤 문제이고 원인을 파악하는 것이다. SameSite이슈를 해결하기 위해 걸린 시간은 1시간 정도로 매우 짧았지만 지금 발생하는 버그의 원인이SameSite때문이란 걸 확인하는 데에는 3~4시간 정도 걸린 매우 힘겨운 문제였다. 진행하는 프로젝트는 프런트와 백 서버를 분리한 프로젝트다. 프런트에서 유저정보와 함께 백서버로 로그인 인증 요청을 하면 백서버에서 검증과정 결과를 프론트로 다시 전달한다. 이때 stateless한 ..

https://yousrain.tistory.com/23

https와 cross domain으로 서버와 통신 시 쿠키 보내는 법

현재 서버와의 통신 사항은 이렇다 프론트엔드와 백엔드가 서로 다른 도메인을 가지고 있다. (cross domain) = 서로 다른 url 프론트엔드와 백엔드 모두 ssl을 끼고 통신한다. (https) 로컬에서 테스트할 때는 서버가 보내준 쿠키를 프론트 단에서 잘 저장했었다. 프론트엔드 서버는 localhost:3000, 백엔드 서버는 localhost:8080에서 호스팅되고 있었다. 프론트엔드가 server side rendering 중이다. 문제는 서버와 프론트를 모두 호스팅하고 https로 통신할 때였다. login을 해도 세션 쿠키가 브라우저에 저장되지 않아(혹은 쿠키는 받았지만 서버에 보내지 않아) 로그인이 정상적으로 성공하지 않았다. 이 글을 작성하고 보니 쿠키를 서버로 보내지 않았던 거다. ..

https://blossoming-man.tistory.com/entry/https와-cross-domain에서-서버와-통신-시-쿠키-받는-법

다른 도메인에 쿠키 설정하기

서버와 클라이언트의 도메인이 다를 때 쿠키를 설정하고 CORS 에러를 해결하기

https://velog.io/@ooooorobo/다른-도메인에-쿠키-설정하기

 

결론

• 프론트 local에서 테스트해본 결과 성공적으로 동작한다.