在 Beta 1 中我弄不明白的另外一件事是將 SecureString 廣泛地集成到框架中。迄今為止，我發現唯一使用它的地方是 ProcessStartInfo。該類只有更充分地集成到框架中，它的真正功能才能實現。
例如，我希望看到下面的構造函數：
public SqlConnection(SecureString connStr);
我還希望看到包裝 Win32® 函數（如 CredUIPromptForCredentials）的托管類，這樣我可以詢問用戶密碼，從而返回 SecureString。集成是該功能成功的關鍵。
除了 SecureString，該命名空間中還有另一個新類吸引了我的眼球：SecurityContext。在 Beta 1 版本中甚至還有該類的一些文檔，這是個功能極其強大的類！它允許您捕捉某個線程的安全性上下文，并將其還原到另一個線程上。這包括代碼訪問安全 (CAS) 線程標記，如 Assert 和 PermitOnly，還包括非托管線程的模擬標記。
該類還有一些看起來不一致的函數，如 SuppressFlow，該函數控制 CAS 標記是否從一個線程流動到另一個線程（通常是這樣）。那么就有一個令人吃驚的結果：SuppressFlowWindowsIdentity。任何在 Windows? 中已經較長時間從事安全性編程的人員都知道，當您開始一個新線程或通過委托執行異步調用時，模擬標記并不流動到新線程。這種不起眼的安全性局限在過去的幾年中已經刺痛了不知多少個開發人員。如果 SecurityContext 提供一種可以抑制 WindowsIdentity 在線程間流動的函數，那一定意味著 .NET Framework 現在可以自動地流動模擬標記。
為了測試這一點，我編寫了一些稱為 LogonUser 的代碼并模擬了結果標記。然后，我使用 WindowsIdentity 上 GetCurrent 方法的一種全新重載來確定我是否是在模擬（這一點隨后有更多講述）。我從四個不同的地方調用該函數：主線程，通過 Thread.Start 開始的新線程，通過異步委托開始的輔助線程，以及從我們來自 Win32 的老朋友，CreateThread 開始的線程。對了，我甚至嘗試著測試 QueueUserWorkItem，在過去它對流動安全性上下文的處理已經有些不同（特別是對 CAS 標記）。下面是輸出結果：
Main thread
Thread 2488 is impersonating V-CAMP-XP\alice
Testing Thread.Start
Thread 2508 is impersonating V-CAMP-XP\alice
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
