关于前端:请求头携带Cookie失败

解决办法
1、chrome 地址栏输出 chrome://flags
2、将SameSite by default cookies 和Cookies without SameSite must be secure设置为 disable

3、重新启动浏览器

Cookie 的 SameSite 属性

Chrome 51 开始，浏览器的 Cookie 新减少了一个 SameSite 属性，用来避免 CSRF 攻打和用户追踪。

一、CSRF 攻打是什么

Cookie 往往用来存储用户的身份信息，歹意网站能够设法伪造带有正确 Cookie 的 HTTP 申请，这就是 CSRF 攻打。

举例来说，用户登陆了银行网站 your-bank.com，银行服务器发来了一个 Cookie。

Set-Cookie:id=a3fWa;

用户起初又拜访了歹意网站 malicious.com，下面有一个表单

<form action="your-bank.com/transfer" method="POST">
  ...
</form>

用户一旦被诱骗发送这个表单，银行网站就会收到带有正确 Cookie 的申请。为了避免这种攻打，表单个别都带有一个随机 token，通知服务器这是实在申请

<form action="your-bank.com/transfer" method="POST">
  <input type="hidden" name="token" value="dad3weg34">
  ...
</form>

这种第三方网站疏导收回的 Cookie，就称为第三方 Cookie。它除了用于 CSRF 攻打，还能够用于用户追踪。

比方，Facebook 在第三方网站插入一张看不见的图片。

<img src="facebook.com" style="visibility:hidden;">

浏览器加载下面代码时，就会向 Facebook 收回带有 Cookie 的申请，从而 Facebook 就会晓得你是谁，拜访了什么网站。

二、SameSite 属性

Cookie 的 SameSite 属性用来限度第三方 Cookie，从而缩小平安危险。
它能够设置三个值。

• Strict
• Lax
• None

2.1 Strict

Strict最为严格，齐全禁止第三方 Cookie，跨站点时，任何状况下都不会发送 Cookie。换言之，只有以后网页的 URL 与申请指标统一，才会带上 Cookie。

Set-Cookie: CookieName=CookieValue; SameSite=Strict;

这个规定过于严格，可能造成十分不好的用户体验。比方，以后网页有一个 GitHub 链接，用户点击跳转就不会带有 GitHub 的 Cookie，跳转过来总是未登陆状态。

2.2 Lax

Lax规定稍稍放宽，大多数状况也是不发送第三方 Cookie，然而导航到指标网址的 Get 申请除外。

Set-Cookie: CookieName=CookieValue; SameSite=Lax;

导航到指标网址的 GET 申请，只包含三种状况：链接，预加载申请，GET 表单。详见下表。

设置了 Strict 或Lax当前，根本就杜绝了 CSRF 攻打。当然，前提是用户浏览器反对 SameSite 属性。

2.3 None

Chrome 打算将 Lax 变为默认设置。这时，网站能够抉择显式敞开 SameSite 属性，将其设为 None。不过，前提是必须同时设置Secure 属性（Cookie 只能通过 HTTPS 协定发送），否则有效。

上面的设置有效。

Set-Cookie: widget_session=abc123; SameSite=None

上面的设置无效。

Set-Cookie: widget_session=abc123; SameSite=None; Secure

三、参考链接

• Using the Same-Site Cookie Attribute to Prevent CSRF Attacks
• SameSite cookies explained
• Tough Cookies, Scott Helme
• [Cross-Site Request Forgery is dead!, Scott Helme](https://scotthelme.co.uk/csr