2015-10-15 4 views
0

У меня есть провайдер аутентификации, использующий HMAC в качестве механизма аутентификации в ServiceStack.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. Мое предположение заключалось в том, что URL-адрес, введенный в клиенте REST, будет таким же, как и IHttpRequest.AbsoluteUri. Тем не менее, существует небольшая, но значительная разница, которая, как я полагаю, обусловлена ​​балансировкой нагрузки.

https://service.com/auth/hmac 

преобразовывается в AbsoluteUri:

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

(я могу видеть это в журналах ServiceStack)

Вопрос заключается в том, есть ли лучший IHttpRequest свойство следует использовать для избегайте этого, или мне нужно вручную разбить Uri на C#, чтобы вырезать номер порта? Последнее кажется немного взломанным.

Update:

Я знаю, что это будет работать, но есть лучший способ?

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 

ответ

0

Является ли ваш клиент концом C# тоже (как в контроллере). Если это так, то вы можете создать новый System.Uri со своего другого URL-адреса (без номера порта), а затем сделать ToString.

Таким образом, вы будете иметь возможность напрямую сравнить URL-адреса, используя один и тот же синтаксический. Лучше снимать порт, поскольку он позволяет различать разные номера портов.

+0

Я не уверен, что я последую за тобой. Клиент не принимает порт. Сервер AbsoluteUri возвращает Uri с портом. Вы предлагаете: «var u1 = new UriBuilder (req.AbsoluteUri); string clean = u1.Uri.ToString(); 'потому что это тоже порт? Главным образом из-за этого: «Строка, возвращаемая этим методом, не содержит информации о порте, когда порт является портом по умолчанию для схемы». (msdn.microsoft.com/en-us/library/system.uri.tostring.aspx) – Junto

+0

Да, я предлагаю, чтобы оба Uri в сравнении были созданы как System.Uri. Заметка о том, что номер порта не возвращается, не имеет значения, поскольку идентичные Urls будут отображаться точно таким же образом, отображая или удерживая номер порта в соответствии с правилами метода. Если они выглядят иначе, тогда должна быть разница. –

+0

Я предполагаю, что это был вопрос моего вопроса. Балансировщик нагрузки намеренно добавляет порт в URI запроса. Первоначальный запрос, сделанный клиентом, не указывает порт, поэтому процесс выходит из строя. Мое предложенное решение выше, но я искал улучшения для этого, в частности решения, которые уже встроены в ServiceStack IHttpRequest, который является свободной оболочкой вокруг Http.Current.Request – Junto