Web Api 2 Controller се държи различно в Visual Studio 2012 спрямо 2013, Authorize Attribute

Точният, прецизен, .sln файл, който съдържа моя уеб проект MVC 5/ Web Api 2, се държи по един начин, когато го стартирам от инсталацията на Visual Studio 2012, и се държи по съвсем различен начин, когато го стартирам от Visual Studio 2013.

По-специално, имам CustomerController, който наследява от ApiController, който отговаря на OData заявки (не, не съм наследил от OdataController). Всичко работи чудесно, когато се изпълнява от Visual Studio 2012 (и когато се внедри на моя тестов уеб сървър 2008 R2). Когато го стартирам от Visual Studio 2013, получавам този отговор:

{"Message":"Authorization has been denied for this request."}

Да, моят контролер е украсен с атрибут Authorize:

<Authorize(Roles:="MYCORP\my_activedirectory_group")>
Public Class CustomerController

След това, когато премахна този атрибут, мога да стартирам проекта си локално от Visual Studio 2013 (което в момента стартира моя проект в IIS Express, докато във VS 2012 го стартира от ASP.NET Development сървър)

каква е сделката


iis-express asp.net-web-api2 visual-studio-2013 authorize-attribute visual-studio-2012
person bkwdesign    schedule 20.05.2015    source източник

Отговори (1)


arrow_upward
0
arrow_downward

Добре, разбрах го, след като помислих върху това.

Очевидно IIS Express не е конфигуриран да използва удостоверяване на Windows.

Щракнах с десния бутон върху иконата на IIS Express в системната област и избрах „Покажи всички приложения“

В получения диалогов прозорец избрах едно от приложенията, изброени в мрежата (само 1 в списъка, тъй като имам само 1, работещо от Visual Studio)

След като елемент на приложение бъде маркиран, можете да видите хипервръзката/пътя на файла към applicationhost.config

В рамките на този конфигурационен файл редактирах този раздел, намерих около 1/3 от пътя надолу в елемент ‹security›:

<authentication>
    <anonymousAuthentication enabled="false" userName="" />
    <basicAuthentication enabled="false" />
    <clientCertificateMappingAuthentication enabled="false" />
    <digestAuthentication enabled="false" />

    <iisClientCertificateMappingAuthentication enabled="false"></iisClientCertificateMappingAuthentication>

    <windowsAuthentication enabled="true">
        <providers>
           <add value="NTLM" />
           <add value="Negotiate" />
        </providers>
    </windowsAuthentication>
</authentication>

По-горе зададох всички атрибути „enabled“ на „false“, с изключение на последния в елемента windowsAuthentication. За нашата среда винаги премествам NTLM на първа позиция в изброените доставчици.

person bkwdesign    schedule 20.05.2015
comment
Така че все пак не бяха ябълки за ябълки. - person Robert Harvey; 20.05.2015
comment
Е, решението не се беше променило, но средите на Visual Studio, които сравнявах, използваха различни хост среди, което ме хвана неподготвен - person bkwdesign; 21.05.2015