ASP.net會話cookie丟失或刪除

我有一個ASP.NET 2.0網站，用於存儲會話中的用戶ID以表明他們已登錄。在某些情況下，用戶似乎不會保持登錄狀態。去過的監測提琴手交通，以及一些細節，我發現：ASP.net會話cookie丟失或刪除

問題是運行IE7運行時，IE7和項目經理的筆記本電腦時，可重複的100％我的一箇舊的筆記本電腦。在我運行IE7的筆記本電腦上，或者在運行FF時，這些筆記本電腦中都沒有發生這個問題。
該問題僅在生產中發生 - 不在開發，內部分段或客戶端分段中。生產是唯一的負載平衡環境，但上面提到的可重複性使得我對負載平衡提出質疑。
當設置Session（「ID」）= 1的頁面向客戶端發送一個響應時，我可以在所有情況下看到一個「Set-Cookie」頭，它創建了ASP.Net_Session_Id cookie（並且它是HttpOnly ）。
對服務器的後續請求將在未出現問題的計算機上的標頭中發送該cookie，但不在計算機上，因此cookie被刪除或「Set-Cookie」標頭被忽略。
登錄工作方式如下：www.DomainX.com上的一個頁面有一個iframe。該iframe的來源是login.DomainY.com上的一個頁面。從login.DomainY.com提供的各種頁面可讓用戶完成登錄/註冊過程。 login.DomainY.com的最後一步是重定向到www.DomainX.com上的一個頁面，包括查詢字符串中的用戶ID。 www.DomainX.com上的這個頁面通常在會話中存儲ID，然後運行一些JS將頂級文檔重定向到新頁面，從而使用戶離開iframe。這是一個已經工作了幾年的流程，有幾個DomainX.com的價值。這裏可能有所不同的是，在這種情況下，JS只是簡單地銷燬iframe和一些包含div的東西。
我在Google Analytics Cookie中發現問題的場景和不出現的場景之間的另一個區別。當login.DomainY.com/FinalStep.aspx在iframe中重定向到www.DomainX.com/SaveTheID.aspx時有所不同。如果問題沒有發生，請求SaveTheID.aspx包含各種Google Analytics Cookie（__utma，__utmz等）。當問題發生時，這個請求不包括所有GA cookies（它缺少__utma，__utmz和__utmb）。
生產是login.DomainY.com在SSL下運行的唯一環境，所以我認爲這可能是相關的。但是我們暫時將login.DomainY.com的登臺副本設置爲使用SSL，並且沒有任何效果。

任何想法可能導致這種情況？

編輯：生產環境具有www.DomainX.com和DomainX.com的域。還有另一個已知的問題，即沒有爲這兩個域設置Cookie。這可能與此有關，但在修復版本發佈之前我無法進行測試。

2010-02-05 Joel

有你一起看着提琴手網絡流量 - http://www.fiddler2.com/ - 這是一個偉大的工具查看服務器和瀏覽器之間發送的流量，包括cookie等，並且可以配置爲解密HTTPS流量？ – 2010-02-05 16:45:30

是的，我一直在這樣做; Fiddler是我現在知道的主要信息來源。謝謝，不過。 – Joel 2010-02-05 17:07:45

你會想看看你的會話狀態提供程序，看它是否會在.net應用程序的兩個服務器/實例上工作。如果它們被設置爲inProc，那麼你最肯定會遇到這個問題，因爲每個會話都會綁定到它創建的線程。相反，您希望將此抽象爲兩臺機器都可以訪問的asp.net狀態服務，或者更好的是您應該使用分佈式緩存解決方案，例如Microsoft Velocity項目，該解決方案將在兩臺機器之間分配會話以防萬一停機。

一些其他的方法來解決這個問題是使用的負載均衡器（不推薦）會話粘貼或移動到會工作一個cookie的會話，但可能在你的代碼會讓人頭痛。

在我們的業務，我們有背後的分佈式緩存主次服務器，這樣，如果一臺機器出現故障其他的都可以拿過來。同樣的原則也適用於負載均衡，一旦你開始在應用程序池中擁有多臺機器甚至多個實例，你將不得不爲此編寫代碼。

如果您使用會話速度一定要確保你選擇用於存儲會話緩存非evictable。

來源

2010-02-06 19:36:19 Middletone

您能否解釋爲什麼不推薦在負載平衡器上使用粘性會話？我一直認爲這是個好主意。 – Jacob 2010-02-06 20:42:50

粘滯會話會導致請求始終轉到同一臺服務器。這意味着如果服務器出現故障，請求不會被重新路由。如果它被重新路由，會話將會丟失，除非程序內置了冗餘的會話狀態等。不粘會議強迫你實現冗餘，您的應用程序和設計，它向外擴展，以及支持節點的故障。最後，非粘性會話讓您的路由器更好地管理流量。請求在節點之間分配更均勻，因爲無論哪個框輸入請求都無關緊要。 – Middletone 2010-02-07 17:37:10

我覺得Middletone是除權：它沒有解釋爲什麼這個問題不能用Firefox來repro'd。負載均衡器是第一嫌疑犯;它會是很好看，如果它採取一切，但應用程序服務器離線的一個有一個藉口（如果可行的話，並且在的時候，它能夠處理負載），看看問題是否仍然存在。如果是這樣，它不是負載平衡器，你可以開始尋找其他地方。否則，它是負載平衡器。

順便說一下：粘滯會話不好，因爲它上面的會話不受冗餘保護。此外，負載均衡器無法在某個時間點分發給負載最輕的服務器，只能在會話開始時決定，然後將用戶保留在他/她所在的位置。

如果事實證明您在這裏遇到了負載平衡器問題，我要做的第一件事就是開啓會話粘滯性，然後再尋找另一種解決方案，以適應生產環境的舒緩背景。

來源

2010-02-07 14:25:56 GreenIcicle

拍，我一定是失去了我的cookie，並回復和編輯能力...

我做了修改我的hosts文件探索負載均衡的問題，一點點地直接指向每個IP地址的網絡服務器，並沒有任何影響。我認爲客戶的IT人員會不約而同地要求關閉負載平衡。

我們確實有一個單獨的狀態服務器正在運行，它與在同一臺服務器上託管的其他站點上已經使用了幾年相同。不一定沒有問題，但沒有這樣的問題。

作爲一個創可貼，我目前正在測試其他持久性機制......

來源

2010-02-08 17:57:50 Joel

ASP.net會話cookie丟失或刪除

回答

相關問題