Chrome扩展弹窗打开SameSite=Strict站点如何携带session cookie

可以实现。Chrome扩展拥有高于普通网页的上下文权限，只要配置对应权限、使用合规的扩展API触发导航，就能让请求正常携带SameSite=Strict属性的CRM session cookie，不需要修改CRM服务端的Cookie配置。

你遇到的是浏览器SameSite规则的标准表现：扩展弹窗的运行上下文是chrome-extension://<扩展ID>的独立源，和内部CRM的业务源不属于同站，直接通过弹窗内的<a>标签点击、普通window.open触发的导航属于跨站上下文发起的请求，浏览器默认会剥离SameSite=Strict类型的Cookie，不会附加到请求头中。

以下方案均基于当前官方支持的Manifest V3扩展规范，按推荐优先级排序：

• 方案1：在用户交互回调中直接调用chrome.tabsAPI打开链接（优先选，零额外权限成本）
  Chrome会将用户在扩展弹窗中主动点击触发、且在同步回调中调用chrome.tabs.create发起的导航，标记为用户主动发起的可信导航，不会触发SameSite=Strict的Cookie拦截。
  弹窗页脚本（popup.js）示例代码：

  // 绑定弹窗内链接/按钮的点击事件
  document.querySelector('#crm-entry').addEventListener('click', () => {
    // *注意：必须在用户点击的同步回调中调用，不能放在fetch、setTimeout等异步逻辑后执行*
    chrome.tabs.create({
      url: 'https://你的内部CRM目标页面地址',
      active: true
    })
  })
  

  该方案不需要额外申请特殊权限，只要在manifest.json中声明tabs基础权限即可，兼容性覆盖所有近期正式版Chrome。
• 方案2：通过CRM域下的内容脚本触发同站导航（适配特殊管控场景）
  如果你的内部CRM有额外的跨站请求管控规则，导致方案1不生效，可以通过内容脚本在CRM源上下文下触发导航，同站上下文发起的请求默认会携带所有SameSite=Strict的Cookie。
  第一步：在manifest.json中声明CRM域的内容脚本注入规则

  {
    "content_scripts": [
      {
        "matches": ["https://你的内部CRM域名/*"],
        "js": ["crm-content.js"]
      }
    ]
  }
  

  第二步：在内容脚本（crm-content.js）中监听扩展消息，执行跳转

  chrome.runtime.onMessage.addListener((msg) => {
    if (msg.type === 'crm-navigate') {
      window.location.href = msg.targetUrl
    }
  })
  

  第三步：弹窗点击事件中优先通过已有CRM标签页触发跳转

  document.querySelector('#crm-entry').addEventListener('click', async () => {
    // 查找当前已打开的CRM域标签页
    const existCrmTabs = await chrome.tabs.query({url: 'https://你的内部CRM域名/*'})
    if (existCrmTabs.length > 0) {
      const targetTab = existCrmTabs[0]
      // 给已有CRM标签发消息触发跳转
      chrome.tabs.sendMessage(targetTab.id, {
        type: 'crm-navigate',
        targetUrl: 'https://你的内部CRM目标页面地址'
      })
      // 激活目标标签页
      chrome.tabs.update(targetTab.id, {active: true})
      return
    }
    // 无已打开的CRM标签时，直接用tabs.create打开
    chrome.tabs.create({url: 'https://你的内部CRM目标页面地址', active: true})
  })
  

• 方案3：通过声明式网络请求规则手动附加Cookie（不推荐，仅极端场景使用）
  你可以通过declarativeNetRequestAPI配置规则，对发往CRM域的请求手动在请求头中附加对应Cookie，但该方案需要提前通过chrome.cookiesAPI获取CRM的Cookie值，存在Cookie过期不同步、多Cookie拼接错误的问题，维护成本极高，非必要不要使用。

• 不要使用已废弃的Manifest V2版本的webRequestAPI拦截修改请求头，当前Chrome已全面限制V2扩展的运行能力，该方案无法在新版浏览器中生效。
• 所有导航触发逻辑必须绑定在用户主动交互（点击、键盘确认）的同步回调中，异步逻辑中触发的导航会丢失用户交互可信标记，SameSite=Strict的Cookie拦截依然会生效。
• 不要尝试在扩展弹窗中通过iframe嵌入CRM页面再触发跳转，弹窗内加载跨源iframe本身就不会携带SameSite=Strict的Cookie，还会引入额外的跨域访问限制问题。

内容的提问来源于stack exchange，提问作者arashb31