多重親和餅乾

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，因爲它只能在單個實例中運行。但這只是因爲我們正在試生產纔有可能。在不久的將來某個時候，我需要擴展到至少兩個實例，因爲天藍色的SLA是有效的。

該問題可以通過將網站domain.com遷移到子域名（f.ex .: www.domain.com）來解決，但我真的不希望這樣做。

理想情況下，我希望負載平衡器檢查所有包含的關聯cookie，而不僅僅是第一個。但直到已修復，我很想知道任何解決方法。據我所知，我可以控制的ARR的唯一方面是應該啓用還是不啓用。

Answer 1

下面是關於這一問題的Azure支持團隊的回覆：

我想讓你知道問題的狀態。產品團隊已經分析了這個問題，他們會研究它。他們一致認爲最好的解決方案是讓ARR遍歷所有的cookies。

不幸的是，現在我們還沒有任何ETA，因此現在最好的解決方法就像您所說的那樣，將www添加到裸域。

說實話，我認爲這是最好的結果。 Azure已經認識到了這個問題，並致力於糾正它。到那時，可能的解決方法，如果你需要粘性會話，是要麼

• 不能同時使用在網站上的裸域和子域不
• 使用共享會話跨網站實例共享應用程序服務計劃，從而完全消除了對ARR的需求。在ASP.NET中，使用SQL，Redis，Azure存儲或其他會話存儲來設置不同的會話狀態提供程序非常簡單。