Заголовок авторизации дампов IIS при перенаправлении после вызова службы WCF без косой черты - PullRequest
Новая
       2

Заголовок авторизации дампов IIS при перенаправлении после вызова службы WCF без косой черты

0 голосов
/ 08 августа 2011

Я собираю службу WCF REST, работающую в экземпляре веб-сайта IIS 7, и использую схему аутентификации HMAC , которая вставляет токен и HMAC в заголовок аутентификации.Пример списка заголовков для типичного запроса может выглядеть следующим образом: 

GET http://api.mydomain.com/Contacts HTTP/1.1
Authorization: 774F035C-FRTB-4207-DDDD-31BF1534AD96:9h0Whke9Bgi3XSHPo/YSXw==
Content-Type: application/xml; charset=utf-8
Host: api.mydomain.com
Connection: Keep-Alive

У меня настроена служба с использованием маршрутизации вместо файла .svc, поэтому мой Global.asax выглядит следующим образом: 

    protected void Application_Start(object sender, EventArgs e)
    {
        RouteTable.Routes.Add(new ServiceRoute("Users", new WebServiceHostFactory(), typeof(UsersService)));
        RouteTable.Routes.Add(new ServiceRoute("Widgets", new WebServiceHostFactory(), typeof(WidgetsService)));
    }

Проблема в том, что когда служба объявляется с такой маршрутизацией, если IIS получает вызов на WebGet uri без завершающей косой черты , он выполняет перенаправление 307 на uri с косой чертой.Можно подумать, полезно, но проблема в том, что редирект сбрасывает заголовок авторизации.

Все мои классы обслуживания кошерны и отлично работают во всех остальных отношениях. Есть ли способ для меня, чтобы иметь возможность поддерживать этот заголовок авторизации в случае перенаправления? Я подозреваю, что решение будет конфигурация IIS, хотя я думаю, что я мог бы поставить все видымаршрутизации хаков на месте, чтобы забрать версию uri без косой черты.

Обновление:
Я нашел эту статью , которая проверяет это поведение, нона самом деле ничего не дает.

1 Ответ

0 голосов
/ 09 августа 2011

Так что я не совсем уверен, почему IIS оказывается здесь в центре событий. Когда вы говорите «сбросить заголовок авторизации», что вы имеете в виду? Вы имеете в виду, что он повторно отправляет его как часть перенаправления или не отправляет его?

WCF, вероятно, вы можете предотвратить перенаправление. Это одна из тех вещей, где вы захотите дать кому-нибудь пощечину в Microsoft за почти , чтобы все было правильно. Сам класс UriTemplate имеет возможность игнорировать завершающие косые черты с помощью метко названного свойства IgnoreTrailingSlash . К сожалению, атрибуты WCF WebInvoke/Get на самом деле никак не отображают это свойство и поэтому всегда создают шаблоны, которые точно связаны с тем, что вы вводите в свойство UriTemplate.

Таким образом, самый простой обходной путь, который я допускаю, состоит в том, чтобы перегрузить метод в контракте WCF второй подписью, которая имеет косую черту. Например: 

[OperationContract]
[WebGet(UriTemplate="/Users")]
public List<User> GetUsers()
{
   .... some code here ...
}

[OperationContract]
[WebGet(UriTemplate="/Users/")]
public List<User> GetUsersSlash()
{
   return this.GetUsers();
}

Fugly, верно? Особенно плохо, если это шаблон, который вы хотите повторять снова и снова. Таким образом, еще один вариант, но не такой хакерский, - написать собственную логику селектора операций, которую вы применяете к своему сервису через пользовательское поведение. Подробнее об этом можно узнать в ответе StackOverflow .

...