2010-05-12 93 views

回答

2

簡短的回答是否定的。這是IIS的有意限制,以防止人們依賴於不可靠的東西。

在市場上,您會發現各種硬件負載均衡器,它們將提供基於SSL會話ID的服務器持久性等功能,但由於SSL重新協商可能隨時發生,所以它們不能很好地工作。例如,在Internet Explorer 8中,對於打開到網站的每個標籤,將協商一個新的SSL會話。您可以期待其他多進程瀏覽器的類似行爲。所以,我必須強調,不應該爲任何類型的用戶標識目的使用SSL會話標識。這就是說 - 如果你真的需要一些專門任務的SSL會話ID信息,我建議使用Apache,mod_ssl和mod_proxy作爲你的IIS系統的前端。稍微擺弄一下,你可以強制mod_ssl爲你提供會話ID,然後你可以添加到代理請求到你的IIS服務器作爲查詢字符串參數....或者你可以將它存儲在數據庫中。

+0

thx,我不知道IE執行重新談判,我的默認使用是不可適用的已知... – 2010-05-22 10:02:41

+0

就像進一步的FYI,我挖了一個MS Exchange團隊中的一個傢伙的博客文章,觸及此問題如何影響OWA部署: http://blogs.msdn.com/brad_hughes/archive/2009/10/15/internet-explorer-8-impacts-owa-load-balancing-scenarios.aspx – 2010-05-22 13:25:17

0

添,

你真的「只是」試圖檢索會話ID字符串或切換到SSL時,你也許失去所有的會話信息?這將是一個非常常見的問題,因爲在使用「InProc」會話存儲時,服務器端的會話會丟失,並且客戶端上的會話Cookie可能在未存儲在公共域中時丟失。

因此,你應該切換到狀態服務器或SQL服務器會話管理Web.config文件,例如:

<sessionState mode="SQLServer" 
    cookieless="true" 
    regenerateExpiredSessionId="true" 
    timeout="30" 
    sqlConnectionString="Data Source=MySqlServer;Integrated Security=SSPI;" 
    stateNetworkTimeout="30" /> 

除此之外,我真的不知道爲什麼你不應該能夠也以SSL模式檢索HttpContext.Current.Session.SessionID

某些MSDN鏈接:

也許這有助於以某種方式。

致以問候

+0

嗨,thx回答,但我不是在尋找ASP.NET SessionId,但爲SSL會話標識符(閱讀http://www.eventhelix.com/realtimemantra/networking/ssl.pdf) – 2010-05-21 11:55:14

+0

好吧蒂姆,現在我明白了。然後就忽略我的回覆。我認爲如果這些信息保存在某個地方,唯一的地方可能就是HTTP頭。 「HttpRequest.ServerVariables」包含有趣的預定義變量,如:「ALL_RAW」(所有Http標題)等。請參閱:http://msdn.microsoft.com/en-us/library/ms524602%28VS.90%29.aspx也許這有助於。 – thmshd 2010-05-21 12:38:42