事发：
今天调试一个很久没改过的页面（需登录），出现：登录成功后又跳到了登录页的情况。百思不得其解。
原因：
排查了很久，猜测和samesite有关。我的chrome是80版本,其有个新特性：限制第三方 Cookie发送。登录成功后，重定向到目标页面video.m.abc.com，再次验证登录时，无法发送cookie到验证服务login.m.abc.com。
理一理：
- cookie的发送问题：
- 当在login.m.abc.com登录成功后，会种下cookie。验证登录时，请求会带上login.m.abc.com下所有cookie，包括以以下方式设置的：
Set-Cookie:name=xiaoming; // 只可在login.m.abc.com下获取
Set-Cookie:name=xiaoming;Domain=.m.abc.com; // 可在.m.abc.com及其子域下获取。
- samesite的限制： 在form表单，img标签上发送跨域请求，容易造成csrf攻击。samesite就是为了防止这种情况。通过响应设置，分为以下情况：
Set-Cookie: CookieName=CookieValue; SameSite=Strict; // 相关资料名曰：url必须一致
Set-Cookie: CookieName=CookieValue; SameSite=Lax; // 只在a标签，link预加载和get表单才能携带cookie
Set-Cookie: widget_session=abc123; SameSite=None; Secure // 不限制，但需要https传输
- 浏览器的samesite和响应设置的samesite有啥关系？ 上面一点是从站点本身出发的，但作为一个浏览器的用户，我肯定希望越安全越好，而且自己有一定的控制权。 地址栏输入chrome://flags
- 如果启用第一条，将未指定SameSite属性的cookie视为SameSite=Lax。
- 在第一条启用的前提下，启用第二条，会更加严格的要求传输必须为https。
- 结果：
- 尝试解决：想要和之前一样，跨域时带上cookie，必须要服务端的配合。samesite设置为none，且在https下传输。查看cookie后，已经有none属性，问题可能存在https。
- 乌龙的原因：所谓的限制发送cookie，是在跨站原则上的，不同于cros，www.taobao.com 和 www.baidu.com 是跨站，www.a.taobao.com 和 www.b.taobao.com 是同站，后者不会有samesite的影响。
- 锲而不舍：我发现在chrome的模拟手机的调试时，没有登录问题，所以我猜测。这次乌龙事件和samesite无关，taobao 2月对服务进行改造的时候顺便判断了user-agent，如果是pc模式就无法登录。
