问题产生
问题复现：
A项目页面使用 iframe 引用了B项目
B项目登录页面输入账号密码后点击登录 无法跳转
尝试解决：
- 在B项目修改了跳转方式 但无论是 this.$router.push 还是 window.herf 都无法实现跳转
- 在iframe中使用 sandbox 沙箱属性 无法
- 更换浏览器 发现尤其是Chrome内核浏览器 如Edge 谷歌浏览器 甚至于Safari 均无法正常跳转 但火狐浏览器可以正常访问
- 尝试更换旧版本（51）之前的 Chrome 浏览器 问题解决 确定是SameSite所产生问题
产生原因
在《Web 安全漏洞之 CSRF》中了解到，CSRF 的本质实际上是利用了 Cookie 会自动在请求中携带的特性，诱使用户在第三方站点发起请求的行为。
Chrome 51 开始，浏览器的 Cookie 新增加了一个SameSite属性，可用于防止 CSRF 攻击和用户追踪。CSRF和用户跟踪的共同特点就是在访问网站A时，在给网站B发请求的时候，也会携带上网站B的cookie。而chrome 的samesite属性用来限制第三方 Cookie（第三方的理解是，URL中的网站是第一方；用户浏览器是第二方；除此之外的是第三方）。
samesite共有三个值，分别是Strict，Lax和None。其中，Strict最为严格，完全禁止第三方 Cookie，跨站点时，任何情况下都不会发送 Cookie。换言之，只有当前网页的 URL 与请求目标一致，才会带上 Cookie。Lax规则稍稍放宽，大多数情况也是不发送第三方 Cookie，但是导航到目标网址的 Get 请求除外。具体可以参照下表。这样，如果浏览器支持samesite，那么可以有效地防止CSRF攻击。但同时，也对一些应用造成了麻烦，只要是涉及到身份的网页应用，都无法在从其他网站跳转时正常地使用。
从上图可以看出，对大部分 web 应用而言，POST 表单，iframe，AJAX，Image 这四种情况从以前的跨站会发送三方 Cookie，变成了不发送。
POST表单和AJAX请求在跨站请求的时候不发送Cookie是ok的， 这样可以有效阻止跨站请求伪造攻击。
Image不发送Cookie其实影响比较小，因为大部分静态资源都会放在CDN上， 不随业务变化，可以实现强缓存。
而iframe一般都是跨站的，所以受影响相对较大。
解决方式
1.修改浏览器配置项（Chrome）
由于SameSite是从 Chrome51 版本后出现 所以 Chrome51 版本之前的用户是正常显示的 故不用操作
版本在 Chrome51 - Chrome91 之间
通过可视化图形界面在手动关停 SameSite 如图所示
把SameSite by default cookies设置为disabled 重启浏览器即可正常使用
版本在 Chrome91 - Chrome94 之间
右击桌面的Chrome（Edge同理） - 属性
在目标后输入以下命令
--disable-features=SameSiteByDefaultCookies;
版本在Chrome94 以上
嗝屁凉凉寄
2.修改浏览器配置项（火狐）
地址栏输入 about:config 进入配置
再输入 network.cookie.sameSite.laxByDefault 搜索
默认应该为false false时则正常访问 如果为true 则会产生以上问题 可双击修改测试
