问题产生
问题复现：
A项目页面使用 iframe 引用了B项目
B项目登录页面输入账号密码后点击登录 无法跳转
尝试解决：
在B项目修改了跳转方式 但无论是 this.$router.push 还是 window.herf 都无法实现跳转在iframe中使用 sandbox 沙箱属性 同样无法实现跳转更换浏览器 发现尤其是Chrome内核浏览器 如Edge 谷歌浏览器 甚至于Safari 均无法正常跳转 但火狐浏览器可以正常访问尝试更换旧版本（51）之前的 Chrome 浏览器 以及操作调试火狐浏览器的SameSite配置项 问题解决 确定是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 则会产生以上问题 可双击修改测试
推荐阅读
发表评论