WCF，自定義會員供應商和HttpContext

Question

好吧，我真的會在這裏顯示我的愚蠢的ASP.NET安全模型，但在這裏。

我有一個WCF網絡服務，我設法破解我的方式，讓它通過我的自定義成員資格提供程序管道。

我的成員資格提供者覆蓋了「ValidateUser」，其中我嘗試從我們的SQL服務器實例中加載用戶對象和數據。到目前爲止，所有的好東西，我檢索信譽，加載用戶對象，並返回true，如果我沒有在路上碰到任何顛簸。

在這一點上，我通常會將用戶對象（或ID）填充到會話中，或者實際上只是一些可在請求的整個生命週期內訪問的狀態包。我碰到的問題是HttpContext在這個時候是null，即使Im使用ASP compatability屬性。

我還有什麼其他選擇？乾杯，克里斯。

編輯：

只是爲了澄清什麼，我想做的事情。我想通過用戶憑證在服務器上進行身份驗證，一旦發生這種情況，我想保留已驗證的用戶的某處的詳細信息，我只能訪問服務請求的生命週期。這將是Http.Current.Items的等價物嗎？

是否有任何對象實例化每個請求，我可以通過一個靜態屬性（即類似的方式來訪問HttpContext.Current）訪問？我認爲OperationContext就是這個，但是這也是null？

這真的可以是這樣一個罕見的問題嗎？在整個處理請求過程中，發送creds>檢索用戶> stuff用戶的某處以供訪問。看起來很常見，我錯過了什麼？

乾杯，克里斯。

Answer 1

基本上，對於WCF，首選的最佳實踐解決方案是使用按呼叫激活，例如，每個新的請求/調用都會獲取服務類的新實例，並且會爲每個請求完成所有必需的步驟，如身份驗證和授權。

這可能聽起來效率低下，但是網絡應用程序，尤其是Web服務，只要有可能就應該完全無狀態。把東西放入「狀態包」只是要求進一步的問題 - 你怎麼知道何時使緩存的證書副本無效？如果用戶存在您的應用程序，但Cookie保留在他的機器上會怎麼樣？

總而言之，我強烈建議儘量習慣每次都做這些步驟的想法。是的，它需要一定的處理時間 - 但另一方面，您可以在固有的無狀態環境中免除國家管理方面的許多悲痛 - 無論您如何看待它，總是一團糟。 ..

如果你仍然堅持這個kludge，你可以打開一個ASP.NET的「compabitility」模式的WCF應該讓你訪問HttpContext - 但再次強烈建議不要這樣做。第一個也是最明顯的限制是，當然，這種ASP.NET兼容模式只有在IIS中託管WCF服務時纔有效 - 我自己也不想在生產代碼中執行此操作。

要打開ASP.NET兼容模式，請在web中使用此設置。配置：

<system.serviceModel> 
    <serviceHostingEnvironment 
     aspNetCompatibilityEnabled="true"/> 
</system.serviceModel> 

，你需要有相應的屬性來裝飾您的服務實現（類實現服務合同）：

[AspNetCompatibilityRequirements(RequirementsMode= 
     AspNetCompatibilityRequirementsMode.Allowed)] 
class YourService : IYourService 

的AspNetCompatibilityRequirementsMode可以NotAllowed，Allowed或Required。

欲瞭解更多信息和更深入的說明，請參閱ASP.NET Compatibility Mode