Azure App Gateway会话亲和第三方Cookie兼容CHIPS方案咨询

关于CHIPS分区Cookie的支持情况 #

目前Azure App Gateway没有原生支持将会话亲和Cookie标记为CHIPS分区Cookie（即添加Partitioned属性）。无论是通过Azure门户、ARM模板还是CLI，都找不到直接配置该属性的选项，官方也尚未推送相关功能。

可行的替代方案 #

1. 切换为基于IP的会话亲和（适合对粘性要求不极端的场景） #

App Gateway本身支持基于源IP的会话亲和模式，无需依赖Cookie即可将同一客户端的请求导向同一后端节点：

• 操作方式：在App Gateway的后端HTTP设置里，把会话亲和类型从Cookie改成IP即可。
• 注意点：如果多个用户共享同一个公网IP（比如企业内网用户），他们会被路由到同一个节点，可能造成负载不均；另外用户切换网络（比如从WiFi切到4G）时，IP变化会导致会话粘性失效。

2. 自行在应用层生成会话亲和Cookie #

放弃使用App Gateway自带的Cookie，改为后端应用自主生成带Partitioned属性的会话亲和Cookie：

• 步骤：
  1. 先关闭App Gateway的内置会话亲和功能。
  2. 用户首次请求时，后端生成唯一会话ID，设置Cookie时加上Partitioned; Secure; SameSite=None属性（必须保证站点使用HTTPS）。
  3. 要么在应用层维护会话ID与后端节点的映射关系，要么配合负载均衡的服务器粘性规则实现路由。
• 优势：完全掌控Cookie属性，符合CHIPS规范，从根源上避免第三方Cookie被拦截的问题。

3. 将JS资源部署到父站同域/子域 #

如果能协调资源，把你的JavaScript代码部署到嵌入它的企业网站的同域名或子域名下：

• 这样会话亲和Cookie会被视为第一方Cookie，不会受第三方Cookie拦截政策的影响。
• 需配合调整：和企业网站方协作修改DNS配置、部署SSL证书，确保资源在同域下加载。

4. 用Azure Front Door处理会话亲和 #

Azure Front Door支持自定义会话亲和Cookie的属性，包括添加Partitioned标记。可以考虑：

• 让流量先经过Front Door，由它设置符合要求的会话亲和Cookie，再转发到App Gateway；
• 或者直接用Front Door替换App Gateway的负载均衡功能（根据业务架构评估可行性）。

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