安全的WCF REST Web服務和頭文件

我正在使用C＃編寫一個安全的WCF REST Web服務。安全的WCF REST Web服務和頭文件

我的代碼是這樣的：

public class MyServiceAuthorizationManager : ServiceAuthorizationManager 
{ 
    protected override bool CheckAccessCore(OperationContext operationContext) 
    { 
     base.CheckAccessCore(operationContext); 

     var ctx = WebOperationContext.Current; 
     var apikey = ctx.IncomingRequest.Headers[HttpRequestHeader.Authorization]; 
     var hash = ctx.IncomingRequest.Headers["Hash"]; 
     var datetime = ctx.IncomingRequest.Headers["DateTime"]; 
     ...

我用頭（授權，哈希，日期時間）來存儲有關apikey，當前日期時間和散列請求的URL信息，同時請求主體只包含URL和web服務參數。

例子：

http://127.0.0.1:8081/helloto/daniele

這是正確的方式或者我已經從URL像這樣通過和retieve這些參數：

http://127.0.0.1:8081/helloto/daniele&apikey=123&datetime=20120101&hash=ddjhgf764653ydhgdhgfjiutu56

是有這兩個之間的差異方法？

來源

2012-02-01 danyolgiax

我認爲這兩種方法都適用於簡單的情況。但是，如果您想最大限度地利用本機HTTP行爲，則應該使用標頭方法，而不是URL查詢參數。

這將允許您（例如）使用HTTP響應代碼向客戶端指示資源已永久移動（響應代碼301），以便客戶端可以自動更新鏈接。如果URL包含認證信息，則客戶端不清楚兩個不同的URL實際上是指相同的資源。在其他重定向方案中，標題將自動包含，因此您不必擔心追加參數以重定向URL。

此外，它應該允許更好的客戶端緩存行爲（如果這是您的方案相關）。

作爲另一個例子，使用頭文件可以讓你在不需要客戶端發送消息體的情況下僅基於頭進行認證。這個想法是，您使用標頭進行身份驗證，然後向客戶端發送一個HTTP 100 Continue響應。客戶端不應該發送消息正文，直到它達到100.如果您正在執行具有大型消息主體的POST或PUT，這可能是一個重要的優化。

還有其他的例子，但是否任何給定的相關取決於你的場景和你期望服務的客戶。

總之，我認爲最好是使用協議的元素，因爲它們是明確意圖的 - 這會讓您有機會像客戶期望的那樣行事，並且應該使您的服務更易於訪問，高效且可用從長遠來看。

來源

2012-02-01 21:36:02

根據您的實現，您的必需參數必須在請求的HTTP標頭中傳遞，這肯定不在查詢字符串中。

來源

2012-02-01 18:43:16

我在問我的實現是否正確，或者如果最佳實踐是使用請求體vs頭來傳遞參數並在這種情況下返回參數。對不起，我可憐的解釋。 – danyolgiax 2012-02-01 18:48:07

@danyolgiax您絕對*從不*希望任何敏感數據（例如訪問令牌）包含在URL中。如果可能的話，您可以在標題中找到它，或者如果不可能，則可以是POST主體的一部分。在你的情況下，我會建議所有三個HTTP標頭。 – Randolpho 2012-02-01 21:50:56

@Randolpho雖然你是正確的，你不應該把敏感數據放在一個URL中，把它放在標題或身體幾乎沒有更安全。通過網絡觀看流量的用戶將在url後面的下一行看到這些標題。如果您使用的是HTTPS，則URL和標頭都會被加密。 – 2012-02-01 22:00:30

安全的WCF REST Web服務和頭文件

回答

相關問題