ServiceStack IHttpRequest.AbsoluteUri不匹配瀏覽器客戶端Uri

我有一個身份驗證提供程序，它在ServiceStack中使用HMAC作爲身份驗證機制。ServiceStack IHttpRequest.AbsoluteUri不匹配瀏覽器客戶端Uri

我正在使用IHttpRequest.AbsoluteUri來獲取Uri，但Uri不是我所期望的。由於Uri是我用於HMAC的HMAC基本字符串的核心部分，因此驗證在我們的預生產服務器上失敗。

private string BuildBaseString(IHttpRequest req, string accountCode, string username, string timestamp) 
{ 
    var methodType = req.HttpMethod; 
    var absoluteUri = req.AbsoluteUri; 
    return string.Join("\n", methodType, timestamp, absoluteUri, accountCode, username).ToUpper(); 
}

我使用ServiceStack的超棒日誌記錄功能記錄所有事情。我的假設是，輸入到REST客戶端的URL將與IHttpRequest.AbsoluteUri相同。但是，我認爲這是一個很小但顯着的差異，這是由負載平衡器造成的。

https://service.com/auth/hmac

被轉換爲絕對URI：

https://service.com:80/auth/hmac

（我可以看到這個在ServiceStack日誌）

的問題是，是否有更好的IHttpRequest財產，我應該使用到避免這種情況，還是我需要在C＃中自己手動分解Uri來去掉端口號？後者似乎有點冒失。

更新：

我知道這會工作，但有沒有更好的方法？

var req = authService.RequestContext.Get<IHttpRequest>(); 
var u = new System.Uri(req.AbsoluteUrl); // https://service.com:80/auth/hmac 
string clean = u.GetComponents(UriComponents.AbsoluteUri & ~UriComponents.Port, UriFormat.UriEscaped); 
Console.WriteLine(clean); // https://service.com/auth/hmac

來源

2015-10-15 Junto

您的客戶端是否也是C＃結束（就像在控制器中一樣）。如果是這樣，那麼你可以從你的其他URL（沒有端口號）創建一個新的System.Uri，然後對它做一個ToString。

通過這種方式，您可以直接使用相同的解析來比較URL。優於剝離端口，因爲它允許不同的端口號不同。

來源

2015-10-15 13:42:47

我不知道我跟着你。客戶端不承擔任何端口。服務器AbsoluteUri返回帶有端口的Uri。你是否建議：'var u1 = new UriBuilder（req.AbsoluteUri）;字符串乾淨= u1.Uri.ToString（）;'因爲那也包括端口？主要是因爲：「當端口是該方案的默認端口時，此方法返回的字符串不包含端口信息。」（msdn.microsoft.com/en-us/library/system.uri.tostring.aspx） – Junto

是的，我建議比較中的兩個Uri都被實例化爲System.Uri。關於未返回端口號的註釋不相關，因爲相同的Urls將以完全相同的方式呈現，按照方法的規則顯示或扣留端口號。如果他們渲染不同，那麼肯定會有區別。 –

我想這是我的問題。負載均衡器故意將端口添加到請求URI中。客戶端發出的初始請求不指定端口，因此進程失敗。我建議的解決方案在上面，但我一直在尋找改進，特別是已經內置到ServiceStack IHttpRequest中的解決方案，這是一個圍繞Http.Current.Request的鬆散包裝 – Junto

ServiceStack IHttpRequest.AbsoluteUri不匹配瀏覽器客戶端Uri

回答

相關問題