此 iframe 加载了一个 jwt 令牌,用于对域 B 中的用户进行身份验证。
此响应创建一个会话 cookie 并重新加载 iframe 的页面(从域 B 到域 B 页面)。
此过程适用于 Firefox,但不适用于 Chrome,因为 setcookie 由于 SameSite 设置而被拒绝。
可能我不理解
SameSite
设置,因为身份验证是从域 B 开始到域 B 的,所以我无法理解为什么 SameSite Lax
对 Chrome 无效。
如果 A 和 B 来自不同的站点,例如,A = example,则当域 B 的页面“嵌入”(iframe)在域 A 的页面内时,浏览器采用两种机制拒绝域 B 的页面访问其 cookie。 com 和 B = myapp.org。 第一个机制已经生效了几年:为了可访问,cookie 必须具有
。
SameSite
cookie 属性不仅在页面嵌入期间进行评估,还会在从 A 页面到 B 页面的 navigation期间进行评估。对于导航,
SameSite=Lax
就足够了,但阻止您的是嵌入,而不是导航。第二种机制影响更深远,因为它不依赖于像SameSite
这样的属性(由服务器控制),而是由浏览器单独控制:
第三方cookie阻止。 Chrome(以及其他浏览器供应商,尽管可能还没有 Firefox)目前正在以“隐私保护”为标题推出此功能。 第三方 Cookie 的隐私保护替代方案是分区 Cookie(在一个嵌入中有效,但不适用于跨嵌入)和存储访问 API(提示用户授予对第三方 Cookie 的访问权限) ).