多个亲和 cookie

Question

我有多个具有以下特点的天蓝色网站

• 每个网站都在自己的网络服务器上运行（应用服务计划）
• 他们正在运行多个实例
• 他们在共享域下拥有自己的子域
• 他们（有目的地）启用了 ARR

其中一个站点是主站点，并使用域，没有子域作为其主机名。这是我的问题的根本原因。

分别访问 sub.domain.com 和 domain.com（两个不同的网站，在不同的应用服务计划中）将为每个网站设置一个相似性 cookie。

cookie 规范规定，cookie 应包含在对 cookie 域属性的任何子域的请求中。这意味着，如果我现在访问 sub.domain.com，浏览器将包含两个关联 cookie，因为它在技术上是 domain.com 的子域。

Azure 的负载均衡器显然只查看第一个包含的关联 cookie。如果这恰好是属于domain.com 的那个，它将包含一个无效值，并且负载均衡器将请求循环到一个随机的空闲实例。响应将包含一个带有有效关联 cookie 的 set-cookie 标头，但无论如何这将作为第二个 cookie 包含在后续请求中，问题仍然存在。只要 domain.com 关联 cookie 以及我们的网站所依赖的粘性会话存在，这就会有效地完全禁用所有子域的 ARR。

目前，我已在 domain.com 网站上禁用 ARR，因为它仅在单个实例中运行。但这只是可能的，因为我们处于预生产阶段。在不久的将来，我需要扩展到至少两个实例，因为 Azure SLA 需要它才能生效。

问题可以通过将domain.com 上的站点迁移到子域（例如：www.domain.com）来解决，但我真的不想这样做。

理想情况下，我希望负载均衡器检查所有包含的关联 cookie，而不仅仅是第一个。但在解决之前，我很想知道任何解决方法。据我所知，我可以控制的 ARR 的唯一方面是是否应该启用。

Answer 1

以下是 Azure 支持团队对此问题的回复：

我想让您知道问题的状态。产品团队已经分析了这个问题，他们会调查它。他们一致认为，最好的解决方案是让 ARR 遍历所有 cookie。

不幸的是，现在我们没有任何 ETA，所以目前最好的解决方法是，正如您所说，将 www 添加到您的裸域。

说实话，我认为这是最好的结果。 Azure 已经认识到这个问题，并致力于纠正它。在那之前，如果您需要粘性会话，可能的解决方法是

• 不要在不共享应用服务计划的网站上同时使用裸域和子域
• 使用跨网站实例的共享会话，从而完全消除对 ARR 的需求。在 ASP.NET 中，很容易设置不同的会话状态提供程序，使用 SQL、Redis、Azure 存储或其他东西作为会话存储。