혹시, 배포 환경에서는 도메인이 같아서 쿠키가 사라지지 않는데, 로컬 개발환경에서는 localhost와 배포된 서버의 도메인이 일치하지 않아 쿠키가 날라가서 개발하기가 어려운 상황인데 이럴 때 보통 어떻게 해결하시나요?
How do you usually resolve a situation where the cookies don't disappear in the deployment environment because the domain is the same, but in the local development environment, the domain of localhost and the deployed server don't match, which makes it difficult to develop?
답:
In local development, domain mismatches can indeed cause issues with cookies, especially with SameSite and Securesettings. Here are a few strategies to help manage this:
- Use Environment-Specific Configurations for Cookies:
Set cookie properties based on the environment. In development, you might set:- SameSite=None: Allows the cookie to be sent in cross-site requests. However, this requires Secure to be false in local development if you're not using HTTPS.
- Secure=false: Since localhost often doesn’t use HTTPS, Secure should be false to allow the browser to store the cookie.
- SameSite=Strict or Lax (depending on your needs)
- Secure=true
- Use a Proxy Server in Development:
Setting up a local proxy to make requests to your deployed environment can help match the domain. If you're using tools like webpack or CRA (Create React App), you can set up a proxy to route requests from localhost to your server's domain. This lets cookies behave as if they're on the same domain. - Subdomain for Local Development:
If you have control over DNS, consider setting up a subdomain for development (like dev.yourdomain.com) and use it to mirror the domain of the production server. This way, cookies can be shared, and the environment is closer to production. - Set Cookies Manually for Development:
Sometimes, it helps to manually set cookies in local storage or directly via the browser's DevTools when testing. This isn’t ideal for automated workflows, but it can help when you need quick, temporary access. - Use a Local Tunneling Service:
Tools like ngrok provide a temporary, secure URL that forwards traffic to your localhost. This helps with matching domains and lets you work in an environment closer to production, complete with real HTTPS and domain-specific cookies. - Switch to a Development OAuth Client (if OAuth is involved):
For OAuth flows, create a dedicated development client configured to allow redirects to localhost. This helps maintain cookie handling consistency during testing.
Each of these approaches can be combined as needed based on your development setup and security needs.
로컬 개발에서 도메인 불일치는 실제로 쿠키, 특히 SameSite 및 보안 설정에 문제를 일으킬 수 있습니다. 다음은 이를 관리하는 데 도움이 되는 몇 가지 전략입니다:
쿠키에 환경별 구성을 사용합니다:
환경에 따라 쿠키 속성을 설정합니다. 개발 시 다음과 같이 설정할 수 있습니다:
동일 사이트=없음: 사이트 간 요청에서 쿠키를 전송할 수 있도록 허용합니다. 단, HTTPS를 사용하지 않는 경우 로컬 개발에서 Secure를 false로 설정해야 합니다.
Secure=false: 로컬 호스트는 HTTPS를 사용하지 않는 경우가 많으므로 브라우저에서 쿠키를 저장할 수 있도록 Secure를 false로 설정해야 합니다.
프로덕션에서는 다음과 같이 설정할 수 있습니다:
동일 사이트=엄격 또는 느슨함(필요에 따라)
보안=참
개발 환경에서 프록시 서버 사용:
배포된 환경에 요청을 하도록 로컬 프록시를 설정하면 도메인을 일치시키는 데 도움이 될 수 있습니다. 웹팩이나 CRA(Create React App)와 같은 도구를 사용하는 경우 프록시를 설정하여 로컬 호스트에서 서버의 도메인으로 요청을 라우팅할 수 있습니다. 이렇게 하면 쿠키가 동일한 도메인에 있는 것처럼 동작할 수 있습니다.
로컬 개발을 위한 하위 도메인:
DNS를 제어할 수 있는 경우 개발용 하위 도메인(예: dev.yourdomain.com)을 설정하고 이를 사용하여 프로덕션 서버의 도메인을 미러링하는 것이 좋습니다. 이렇게 하면 쿠키를 공유할 수 있고 환경이 프로덕션에 더 가까워집니다.
개발용 쿠키를 수동으로 설정하기:
테스트할 때 로컬 저장소에 쿠키를 수동으로 설정하거나 브라우저의 개발자 도구를 통해 직접 설정하는 것이 도움이 되는 경우가 있습니다. 이 방법은 자동화된 워크플로에는 적합하지 않지만 빠른 임시 액세스가 필요할 때는 도움이 될 수 있습니다.
로컬 터널링 서비스 사용:
ngrok과 같은 도구는 로컬호스트로 트래픽을 전달하는 임시 보안 URL을 제공합니다. 이렇게 하면 도메인을 일치시키는 데 도움이 되며 실제 HTTPS 및 도메인별 쿠키를 사용하여 프로덕션 환경에 가까운 환경에서 작업할 수 있습니다.
개발 OAuth 클라이언트로 전환합니다(OAuth가 포함된 경우):
OAuth 플로우의 경우 로컬호스트로의 리디렉션을 허용하도록 구성된 전용 개발 클라이언트를 만듭니다. 이렇게 하면 테스트 중에 쿠키 처리 일관성을 유지하는 데 도움이 됩니다.
이러한 각 접근 방식은 개발 설정 및 보안 요구 사항에 따라 필요에 따라 결합할 수 있습니다.
2. 질문
Downloading from the server is also allowed on the server If you register the domain localhost, it shouldn't be a problem, but are you using a commercial server instead of a development server?
(The project server is separated from the development server and the actual deployment server, and the cookie keeps disappearing locally, and I tested it in the actual deployed environment because I was curious, but it sticks well at this time.)
Also, is it normal for cookies to be saved but disappear on refresh?
Some developers said they had the same situation when using the jwtoken feature, and temporarily set sameSite=None to solve it.
Additionally, safari doesn't even save the cookie, chrome saves it temporarily, but when I refresh with a session cookie, it disappears.
서버에서 내려주는것도 서버에서 허용 도메인 localhost 등록해두면 딱히 문제되지 않을텐데..설마 개발서버가 아닌 상용서버에 붙으시는건가요..?
(프로젝트 서버가 개발용 서버랑 실제 배포용 서버는 분리되어있고, 로컬에서는 쿠키가 계속 사라지는 현상이 발생하고, 궁금해서 실제 배포된 환경에서 테스트해봤는데 이때는 잘 붙어있네요.)
그리고 쿠키가 저장은 되는데 새로고침하면 사라지는건 정상인가요?
jwt토큰 기능 사용할 때 똑같은 상황 겪었는데 임시로 sameSite=None으로 설정해서 해결했다는 개발자들도 있습니다.
추가로 사파리는 쿠키가 저장조차 안되고 크롬은 일시적으로 저장은 해주는데 세션 쿠키식으로 새로고침하면 쿠키가 날라간다고 합니다.
답:
It sounds like the separation of environments and some browser-specific behaviors are causing cookie issues, especially with SameSite and session cookies. Here are a few more detailed steps and considerations that might help:
- Check Cookie Domain and SameSite Settings:
Since the project server is separate from the deployment server, ensure that cookies have the Domain attribute set to include both environments (if possible) to ensure persistence. Setting SameSite=None can help in cross-origin scenarios, but as you observed, it may cause inconsistencies across browsers, especially with Safari, which has stricter policies. - Ensure Cookies Aren’t Marked as Third-Party in Safari:
Safari is known for its restrictive cookie policy, especially for third-party cookies, even with SameSite=None. Testing in an environment where the domain of the cookie aligns with the domain of your local server (such as using a proxy or a subdomain that mimics production) can help avoid these restrictions. - Chrome and Session Cookies:
If session cookies in Chrome disappear on refresh, it may be related to cookie expiration or session handling in the development environment. Chrome may consider the session closed when the page refreshes if there's any issue with cookie handling or if it interprets the session differently locally. Ensure your cookie's expiration is set explicitly in development to verify if this is the issue. - Use a Commercial Server Domain in Development:
If you’re able to use a commercial server with a registered domain for development, this would closely mimic production and avoid some of the issues with localhost. If that’s not feasible, using a tunneling service like ngrok or setting up a subdomain specifically for local development (like dev.yourdomain.com) could give you more control and reduce the inconsistencies. - Browser-Specific Testing:
Since Safari behaves differently with cookie handling, you may need to adjust cookie settings specifically for that browser or implement a fallback (e.g., local storage as an alternative for storing JWTs) for testing purposes. Safari’s Intelligent Tracking Prevention (ITP) often blocks cookies that it deems "non-essential," so make sure your cookie attributes comply with its guidelines.
These steps should help mitigate some of the issues across different environments and browsers.
환경 분리와 일부 브라우저별 동작으로 인해 쿠키 문제가 발생하는 것 같습니다. 특히 SameSite 및 세션 쿠키의 경우 더욱 그렇습니다. 다음은 도움이 될 수 있는 몇 가지 자세한 단계와 고려 사항입니다:
쿠키 도메인 및 SameSite 설정을 확인합니다:
프로젝트 서버는 배포 서버와 분리되어 있으므로 쿠키의 도메인 속성이 두 환경을 모두 포함하도록 설정되어 있는지(가능한 경우) 확인하여 지속성을 보장하세요. 동일 사이트=없음으로 설정하면 교차 출처 시나리오에서는 도움이 될 수 있지만, 앞서 살펴본 것처럼 브라우저 간에 불일치가 발생할 수 있으며, 특히 더 엄격한 정책을 적용하는 Safari의 경우 더욱 그렇습니다.
Safari에서 쿠키가 타사로 표시되지 않았는지 확인합니다:
Safari는 특히 타사 쿠키에 대한 제한적인 쿠키 정책으로 유명하며, SameSite=None을 사용하더라도 마찬가지입니다. 쿠키의 도메인이 로컬 서버의 도메인과 일치하는 환경에서 테스트하면(예: 프록시 또는 프로덕션을 모방하는 하위 도메인 사용) 이러한 제한을 피하는 데 도움이 될 수 있습니다.
Chrome 및 세션 쿠키:
Chrome의 세션 쿠키가 새로고침 시 사라지는 경우 쿠키 만료 또는 개발 환경의 세션 처리와 관련이 있을 수 있습니다. 쿠키 처리에 문제가 있거나 로컬에서 세션을 다르게 해석하는 경우 페이지가 새로고침될 때 Chrome은 세션이 종료된 것으로 간주할 수 있습니다. 개발 환경에서 쿠키 만료가 명시적으로 설정되어 있는지 확인하여 이 문제가 있는지 확인하세요.
개발 중인 상용 서버 도메인을 사용하세요:
등록된 도메인이 있는 상용 서버를 개발용으로 사용할 수 있다면 프로덕션 환경과 매우 유사하여 로컬 호스트와 관련된 몇 가지 문제를 피할 수 있습니다. 이것이 불가능하다면 ngrok과 같은 터널링 서비스를 사용하거나 로컬 개발 전용 하위 도메인(예: dev.yourdomain.com)을 설정하면 더 많은 제어권을 확보하고 불일치를 줄일 수 있습니다.
브라우저별 테스트:
Safari는 쿠키 처리와 관련하여 다르게 작동하므로 테스트 목적으로 해당 브라우저에 맞게 쿠키 설정을 조정하거나 폴백(예: JWT를 저장하기 위한 대안으로 로컬 저장소)을 구현해야 할 수 있습니다. Safari의 지능형 추적 방지(ITP)는 '필수적이지 않은' 쿠키를 차단하는 경우가 많으므로 쿠키 속성이 해당 지침을 준수하는지 확인하세요.
이러한 단계를 수행하면 다양한 환경과 브라우저에서 발생하는 일부 문제를 완화하는 데 도움이 됩니다.
3.질문
Samesite none?
Setting SameSite=None for a cookie allows it to be included in cross-site requests, which is essential when your frontend and backend are on different domains (as in a local development environment versus production). However, there are some important considerations and potential caveats:
- Secure Requirement:
When SameSite=None is set, the Secure attribute must also be set, meaning the cookie will only be sent over HTTPS. In development, this can be an issue if you’re using http://localhost, as it’s not an HTTPS environment. Some workarounds include:- Using a local tunneling service (like ngrok) to expose an HTTPS URL for your local server.
- Setting up a self-signed SSL certificate on localhost (though this can be a bit cumbersome and might not work well in all cases).
- Browser Behavior:
Different browsers handle SameSite=None differently. For instance:- Chrome: Chrome generally supports SameSite=None but requires Secure for it to work properly.
- Safari: Safari has stricter cookie policies and may block SameSite=None cookies if they don’t come from a top-level navigation (e.g., a direct link rather than an embedded iframe). It may also apply Intelligent Tracking Prevention (ITP) rules, blocking cookies it deems non-essential.
- Usage in Development:
In a local development environment where HTTPS isn’t always feasible, setting SameSite=None; Secure=falsecan sometimes work, but this varies by browser. If SameSite=None is absolutely necessary for testing, using an HTTPS local tunneling service or a local domain (like dev.yourdomain.com) that matches production as closely as possible can improve consistency. - Session Cookies:
For session cookies, setting SameSite=None and Secure should help maintain them across different domains (e.g., your frontend and backend servers). But without HTTPS, session cookies might still disappear due to browser security policies, especially in Safari and newer versions of Chrome.
In your case, setting SameSite=None may help if cross-site cookie handling is causing issues. However, consider pairing this with an HTTPS environment (via tunneling or subdomain setup) for the most consistent experience across different browsers.
쿠키에 SameSite=None을 설정하면 크로스 사이트 요청에 쿠키를 포함할 수 있으며, 이는 프론트엔드와 백엔드가 서로 다른 도메인에 있을 때(로컬 개발 환경과 프로덕션 환경에서처럼) 필수적인 기능입니다. 하지만 몇 가지 중요한 고려 사항과 잠재적인 주의 사항이 있습니다:
보안 요구 사항:
동일 사이트=없음으로 설정된 경우 보안 속성도 설정해야 하며, 이는 쿠키가 HTTPS를 통해서만 전송됨을 의미합니다. 개발 환경에서 http://localhost 을 사용하는 경우 HTTPS 환경이 아니므로 문제가 될 수 있습니다. 몇 가지 해결 방법은 다음과 같습니다:
로컬 터널링 서비스(예: ngrok)를 사용하여 로컬 서버의 HTTPS URL을 노출합니다.
로컬 호스트에 자체 서명된 SSL 인증서 설정(약간 번거로울 수 있으며 모든 경우에 잘 작동하지 않을 수 있음).
브라우저 동작:
브라우저마다 동일 사이트=없음을 다르게 처리합니다. 예를 들면 다음과 같습니다:
Chrome: Chrome은 일반적으로 SameSite=None을 지원하지만 제대로 작동하려면 Secure가 필요합니다.
Safari: Safari는 더 엄격한 쿠키 정책을 적용하며, 최상위 탐색(예: 임베드된 iframe이 아닌 직접 링크)에서 제공되지 않는 경우 SameSite=None 쿠키를 차단할 수 있습니다. 또한 지능형 추적 방지(ITP) 규칙을 적용하여 불필요하다고 판단되는 쿠키를 차단할 수도 있습니다.
개발 환경에서의 사용:
HTTPS를 항상 사용할 수 없는 로컬 개발 환경에서는 SameSite=None; Secure=false를 설정해도 작동할 수 있지만 브라우저에 따라 다릅니다. 테스트에 SameSite=None이 꼭 필요한 경우 HTTPS 로컬 터널링 서비스 또는 프로덕션과 최대한 일치하는 로컬 도메인(예: dev.yourdomain.com)을 사용하면 일관성을 향상시킬 수 있습니다.
세션 쿠키:
세션 쿠키의 경우 동일 사이트=없음 및 보안을 설정하면 서로 다른 도메인(예: 프론트엔드 및 백엔드 서버)에서 세션 쿠키를 유지하는 데 도움이 됩니다. 그러나 HTTPS를 사용하지 않으면 브라우저 보안 정책으로 인해 세션 쿠키가 사라질 수 있으며, 특히 Safari 및 최신 버전의 Chrome에서 세션 쿠키가 사라질 수 있습니다.
사이트 간 쿠키 처리로 인해 문제가 발생하는 경우 SameSite=None을 설정하면 도움이 될 수 있습니다. 그러나 여러 브라우저에서 가장 일관된 경험을 제공하려면 터널링 또는 하위 도메인 설정을 통해 이 설정을 HTTPS 환경과 페어링하는 것을 고려하세요.