Włączanie żądań między źródłami w programie ASP.NET Web API 2

Według Jan Wasson

Ta zawartość dotyczy poprzedniej wersji platformy .NET. Nowe Programowanie powinno być używane ASP.NET Core. Aby uzyskać więcej informacji na temat korzystania z internetowego interfejsu API i żądań między źródłami (CORS) w ASP.NET Core, zobacz:

Zabezpieczenia przeglądarki uniemożliwiają stronie internetowej wysyłanie żądań AJAX do innej domeny. To ograniczenie jest nazywane zasadami tego samego źródła i uniemożliwia złośliwym lokacjom odczytywanie poufnych danych z innej lokacji. Czasami jednak może być konieczne, aby inne Lokacje wywoływały internetowy interfejs API.

Udostępnianie zasobów między źródłami (CORS) jest standardem W3C, który umożliwia serwerowi złagodzenie zasad tego samego źródła. Przy użyciu mechanizmu CORS serwer może jawnie zezwolić na niektóre żądania między źródłami podczas odrzucania innych. Mechanizm CORS jest bezpieczniejszy i bardziej elastyczny niż wcześniejsze techniki, takie jak JSONP. W tym samouczku pokazano, jak włączyć mechanizm CORS w aplikacji interfejsu API sieci Web.

Oprogramowanie używane w samouczku

Wprowadzenie

W tym samouczku przedstawiono obsługę mechanizmu CORS w interfejsie API sieci Web ASP.NET. Zaczniemy od utworzenia dwóch projektów ASP.NET — jeden o nazwie "WebService", który hostuje kontroler interfejsu API sieci Web, a drugi o nazwie "WebClient", który wywołuje usługę WebService. Ponieważ dwie aplikacje są hostowane w różnych domenach, żądanie AJAX od klienta WebClient do usługi WebService jest żądaniem między źródłami.

Pokazuje usługę sieci Web i klienta sieci Web

Co to jest "to samo Źródło"?

Dwa adresy URL mają te same źródła, jeśli mają identyczne schematy, hosty i porty. (RFC 6454)

Te dwa adresy URL mają te same źródła:

  • http://example.com/foo.html
  • http://example.com/bar.html

Te adresy URL mają różne źródła niż poprzednie dwa:

  • http://example.net — Inna domena
  • http://example.com:9000/foo.html — Inny port
  • https://example.com/foo.html — Inny schemat
  • http://www.example.com/foo.html — Inna poddomena

Note

Program Internet Explorer nie traktuje portu podczas porównywania źródeł.

Tworzenie projektu usługi WebService

Note

W tej sekcji założono, że wiesz już, jak tworzyć projekty interfejsu API sieci Web. Jeśli nie, zobacz wprowadzenie z interfejsem API sieci Web ASP.NET.

  1. Uruchom program Visual Studio i Utwórz nowy projekt aplikacji sieci Web ASP.NET (.NET Framework) .

  2. W oknie dialogowym Nowa aplikacja sieci Web ASP.NET wybierz szablon pusty projekt. W obszarze Dodaj foldery i podstawowe odwołania dla programu zaznacz pole wyboru internetowy interfejs API .

    Nowe okno dialogowe projektu ASP.NET w programie Visual Studio

  3. Dodaj kontroler interfejsu API sieci Web o nazwie TestController przy użyciu następującego kodu:

    using System.Net.Http;
    using System.Web.Http;
    
    namespace WebService.Controllers
    {
        public class TestController : ApiController
        {
            public HttpResponseMessage Get()
            {
                return new HttpResponseMessage()
                {
                    Content = new StringContent("GET: Test message")
                };
            }
    
            public HttpResponseMessage Post()
            {
                return new HttpResponseMessage()
                {
                    Content = new StringContent("POST: Test message")
                };
            }
    
            public HttpResponseMessage Put()
            {
                return new HttpResponseMessage()
                {
                    Content = new StringContent("PUT: Test message")
                };
            }
        }
    }
    
  4. Aplikację można uruchomić lokalnie lub wdrożyć na platformie Azure. (W przypadku zrzutów ekranu w tym samouczku aplikacja zostanie wdrożona w Azure App Service Web Apps). Aby sprawdzić, czy interfejs API sieci Web działa, przejdź do http://hostname/api/test/ lokalizacji, w której Nazwa hosta jest domeną, w której została wdrożona aplikacja. Powinien zostać wyświetlony tekst odpowiedzi " : Komunikat testowy " .

    Przeglądarka sieci Web wyświetlająca komunikat testowy

Tworzenie projektu WebClient

  1. Utwórz inny projekt aplikacji sieci Web ASP.NET (.NET Framework) i wybierz szablon projektu MVC . Opcjonalnie wybierz pozycję Zmień uwierzytelnianie > bez uwierzytelniania. Nie musisz uwierzytelniać się w tym samouczku.

    Szablon MVC w nowym oknie dialogowym projektu ASP.NET w programie Visual Studio

  2. W Eksplorator rozwiązań Otwórz plik widoki/Home/index. cshtml. Zastąp kod w tym pliku następującym:

    <div>
        <select id="method">
            <option value="get">GET</option>
            <option value="post">POST</option>
            <option value="put">PUT</option>
        </select>
        <input type="button" value="Try it" onclick="sendRequest()" />
        <span id='value1'>(Result)</span>
    </div>
    
    @section scripts {
    <script>
        // TODO: Replace with the URL of your WebService app
        var serviceUrl = 'http://mywebservice/api/test'; 
    
        function sendRequest() {
            var method = $('#method').val();
    
            $.ajax({
                type: method,
                url: serviceUrl
            }).done(function (data) {
                $('#value1').text(data);
            }).fail(function (jqXHR, textStatus, errorThrown) {
                $('#value1').text(jqXHR.responseText || textStatus);
            });
        }
    </script>
    }
    

    Dla zmiennej serviceUrl Użyj identyfikatora URI aplikacji usługi WebService.

  3. Uruchom aplikację WebClient lokalnie lub opublikuj ją w innej witrynie sieci Web.

Po kliknięciu przycisku "Wypróbuj" zostanie przesłane żądanie AJAX do aplikacji usługi WebService przy użyciu metody HTTP wymienionej w polu listy rozwijanej (GET, POST lub PUT). Pozwala to na badanie różnych żądań między źródłami. Obecnie aplikacja usługi WebService nie obsługuje mechanizmu CORS, więc po kliknięciu przycisku zostanie wyświetlony komunikat o błędzie.

Błąd "try" w przeglądarce

Note

Jeśli monitorujesz ruch HTTP w narzędziu takim jak programu Fiddler, zobaczysz, że przeglądarka wysyła żądanie Get, a żądanie jest pomyślne, ale wywołanie AJAX zwraca błąd. Ważne jest, aby zrozumieć, że zasady tego samego źródła nie uniemożliwiają wysłania żądania przez przeglądarkę. Zamiast tego uniemożliwia aplikacji wyświetlanie odpowiedzi.

Debuger sieci Web programu Fiddler pokazujący żądania sieci Web

Włączanie mechanizmu CORS

Teraz włączmy mechanizm CORS w aplikacji usługi WebService. Najpierw Dodaj pakiet NuGet CORS. W programie Visual Studio w menu Narzędzia wybierz pozycję Menedżer pakietów NuGet, a następnie wybierz pozycję konsola Menedżera pakietów. W oknie Konsola Menedżera pakietów wpisz następujące polecenie:

Install-Package Microsoft.AspNet.WebApi.Cors

To polecenie instaluje najnowszy pakiet i aktualizuje wszystkie zależności, w tym biblioteki podstawowych interfejsów API sieci Web. Użyj -Version flagi, aby określić wersję docelową. Pakiet CORS wymaga interfejsu Web API 2,0 lub nowszego.

Otwórz plik _ Start/WebApiConfig. cs aplikacji. Dodaj następujący kod do metody WebApiConfig. Register :

using System.Web.Http;
namespace WebService
{
    public static class WebApiConfig
    {
        public static void Register(HttpConfiguration config)
        {
            // New code
            config.EnableCors();

            config.Routes.MapHttpRoute(
                name: "DefaultApi",
                routeTemplate: "api/{controller}/{id}",
                defaults: new { id = RouteParameter.Optional }
            );
        }
    }
}

Następnie Dodaj atrybut [EnableCors] do TestController klasy:

using System.Net.Http;
using System.Web.Http;
using System.Web.Http.Cors;

namespace WebService.Controllers
{
    [EnableCors(origins: "http://mywebclient.azurewebsites.net", headers: "*", methods: "*")]
    public class TestController : ApiController
    {
        // Controller methods not shown...
    }
}

W przypadku parametru Origins Użyj identyfikatora URI, w którym wdrożono aplikację WebClient. Pozwala to na żądania między źródłami z klienta WebClient, mimo że nie zezwala na wszystkie inne żądania między domenami. Później opisano parametry dla [EnableCors] w bardziej szczegółowy sposób.

Nie uwzględniaj ukośnika na końcu adresu URL początkowych elementów.

Wdróż ponownie zaktualizowaną aplikację sieci Web. Nie musisz aktualizować klienta WebClient. Teraz żądanie AJAX od klienta WebClient powinno zakończyć się pomyślnie. Metody GET, PUT i POST są dozwolone.

Przeglądarka sieci Web przedstawiająca pomyślne wiadomości testowe

Jak działa mechanizm CORS

W tej sekcji opisano, co się dzieje w żądaniu CORS, na poziomie komunikatów HTTP. Ważne jest, aby zrozumieć, jak działa mechanizm CORS, dzięki czemu można prawidłowo skonfigurować atrybut [EnableCors] i rozwiązywać problemy, jeśli elementy nie działają zgodnie z oczekiwaniami.

Specyfikacja CORS zawiera kilka nowych nagłówków HTTP, które umożliwiają żądania między źródłami. Jeśli przeglądarka obsługuje mechanizm CORS, ustawia te nagłówki automatycznie dla żądań cross-Origin; nie musisz wykonywać żadnych dodatkowych czynności w kodzie JavaScript.

Oto przykład żądania między źródłami. Nagłówek "Origin" zapewnia domenę lokacji, która żąda żądania.

GET http://myservice.azurewebsites.net/api/test HTTP/1.1
Referer: http://myclient.azurewebsites.net/
Accept: */*
Accept-Language: en-US
Origin: http://myclient.azurewebsites.net
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; WOW64; Trident/6.0)
Host: myservice.azurewebsites.net

Jeśli serwer zezwala na żądanie, ustawia nagłówek Access-Control-Allow-Origin. Wartość tego nagłówka jest zgodna z nagłówkiem pierwotnym lub jest wartością wieloznaczną " * ", co oznacza, że wszystkie źródła są dozwolone.

HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Content-Type: text/plain; charset=utf-8
Access-Control-Allow-Origin: http://myclient.azurewebsites.net
Date: Wed, 05 Jun 2013 06:27:30 GMT
Content-Length: 17

GET: Test message

Jeśli odpowiedź nie zawiera nagłówka Access-Control-Allow-Origin, żądanie AJAX zakończy się niepowodzeniem. W programie przeglądarka nie zezwala na żądanie. Nawet jeśli serwer zwróci pomyślną odpowiedź, przeglądarka nie udostępni odpowiedzi dla aplikacji klienckiej.

Żądania wstępnego lotu

W przypadku niektórych żądań CORS przeglądarka wysyła dodatkowe żądanie o nazwie "żądanie wstępne", zanim wyśle ono rzeczywiste żądanie dotyczące zasobu.

Jeśli spełnione są następujące warunki, przeglądarka może pominąć żądanie wstępne:

  • Metoda żądania jest GET, główna lub OPUBLIKOWANa, a

  • Aplikacja nie ustawia żadnego nagłówka żądania innego niż Accept, Accept-Language, Content-language, Content-Type lub Last-Event-ID oraz

  • Nagłówek Content-Type (jeśli jest ustawiony) jest jednym z następujących:

    • aplikacja/x-www-form-urlencoded
    • wieloczęściowe/formularz-dane
    • tekst/zwykły

Zasada dotycząca nagłówków żądań dotyczy nagłówków, które są ustawiane przez aplikację przez wywołanie setRequestHeader w obiekcie XMLHttpRequest . (Specyfikacja CORS wywołuje te "nagłówki żądania autorów"). Reguła nie ma zastosowania do nagłówków, które można ustawić w przeglądarce , takich jak User-Agent, Host lub Content-Length.

Oto przykład żądania wstępnego:

OPTIONS http://myservice.azurewebsites.net/api/test HTTP/1.1
Accept: */*
Origin: http://myclient.azurewebsites.net
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: accept, x-my-custom-header
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; WOW64; Trident/6.0)
Host: myservice.azurewebsites.net
Content-Length: 0

Żądanie przed inspekcją używa metody HTTP OPTIONS. Zawiera dwa specjalne nagłówki:

  • Access-Control-Request-Method: metoda HTTP, która będzie używana dla rzeczywistego żądania.
  • Access-Control-Request-Heads: lista nagłówków żądań, które aplikacja ustawi w rzeczywistym żądaniu. (Ponownie nie obejmuje to nagłówków, które są ustawiane w przeglądarce).

Oto przykład odpowiedzi, przy założeniu, że serwer zezwala na żądanie:

HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Content-Length: 0
Access-Control-Allow-Origin: http://myclient.azurewebsites.net
Access-Control-Allow-Headers: x-my-custom-header
Access-Control-Allow-Methods: PUT
Date: Wed, 05 Jun 2013 06:33:22 GMT

Odpowiedź zawiera nagłówek Access-Control-Allow-Methods, który zawiera listę dozwolonych metod i opcjonalnie nagłówek Access-Control-Allow-Heads, który zawiera listę dozwolonych nagłówków. W przypadku pomyślnego przeprowadzenia żądania wstępnego przeglądarka wyśle rzeczywiste żądanie zgodnie z wcześniejszym opisem.

Narzędzia często używane do testowania punktów końcowych z żądaniami opcji wstępnego lotu (na przykład programu Fiddler i Poster) nie domyślnie wysyłają wymaganych nagłówków opcji. Upewnij się, Access-Control-Request-Method że Access-Control-Request-Headers nagłówki i są wysyłane wraz z żądaniem, a nagłówki opcji uzyskują dostęp do aplikacji za pomocą usług IIS.

Aby skonfigurować usługi IIS do zezwalania aplikacji ASP.NET na odbieranie i obsługę żądań opcji, Dodaj następującą konfigurację do pliku web.config aplikacji w <system.webServer><handlers> sekcji:

<system.webServer>
  <handlers>
    <remove name="ExtensionlessUrlHandler-Integrated-4.0" />
    <remove name="OPTIONSVerbHandler" />
    <add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="*" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />
  </handlers>
</system.webServer>

Usunięcie OPTIONSVerbHandler uniemożliwia Obsługiwanie żądań opcji przez usługi IIS. Zastąpienie ExtensionlessUrlHandler-Integrated-4.0 opcji zezwala na dostęp do aplikacji, ponieważ domyślna Rejestracja modułu zezwala tylko na żądania GET, nagłówkowe, post i Debug z adresami URL bez rozszerzenia.

Reguły zakresu dla [EnableCors]

Można włączyć funkcję CORS na akcję, na kontroler lub globalnie dla wszystkich kontrolerów internetowego interfejsu API w aplikacji.

Na akcję

Aby włączyć mechanizm CORS dla jednej akcji, należy ustawić atrybut [EnableCors] dla metody Action. Poniższy przykład umożliwia włączenie mechanizmu CORS GetItem tylko dla metody.

public class ItemsController : ApiController
{
    public HttpResponseMessage GetAll() { ... }

    [EnableCors(origins: "http://www.example.com", headers: "*", methods: "*")]
    public HttpResponseMessage GetItem(int id) { ... }

    public HttpResponseMessage Post() { ... }
    public HttpResponseMessage PutItem(int id) { ... }
}

Na kontroler

Jeśli ustawisz [EnableCors] w klasie kontrolera, ma ona zastosowanie do wszystkich akcji na kontrolerze. Aby wyłączyć mechanizm CORS dla akcji, Dodaj atrybut [DisableCors] do akcji. Poniższy przykład włącza funkcję CORS dla każdej metody z wyjątkiem PutItem .

[EnableCors(origins: "http://www.example.com", headers: "*", methods: "*")]
public class ItemsController : ApiController
{
    public HttpResponseMessage GetAll() { ... }
    public HttpResponseMessage GetItem(int id) { ... }
    public HttpResponseMessage Post() { ... }

    [DisableCors]
    public HttpResponseMessage PutItem(int id) { ... }
}

Globalnie

Aby włączyć mechanizm CORS dla wszystkich kontrolerów interfejsu API sieci Web w aplikacji, należy przekazać wystąpienie EnableCorsAttribute do metody EnableCors :

public static class WebApiConfig
{
    public static void Register(HttpConfiguration config)
    {
        var cors = new EnableCorsAttribute("www.example.com", "*", "*");
        config.EnableCors(cors);
        // ...
    }
}

Jeśli ustawisz atrybut w więcej niż jednym zakresie, kolejność pierwszeństwa to:

  1. Akcja
  2. Kontroler
  3. Globalnie

Ustaw dozwolone źródła

Parametr Origins atrybutu [EnableCors] określa, które źródła mogą uzyskać dostęp do zasobu. Wartość jest rozdzielaną przecinkami listą dozwolonych źródeł.

[EnableCors(origins: "http://www.contoso.com,http://www.example.com", 
    headers: "*", methods: "*")]

Można również użyć symbolu wieloznacznego " * ", aby zezwolić na żądania z dowolnego źródła.

Należy uważnie rozważyć przed zezwoleniem na żądania z dowolnego źródła. Oznacza to, że dosłownie każda witryna sieci Web może wykonywać wywołania AJAX do internetowego interfejsu API.

// Allow CORS for all origins. (Caution!)
[EnableCors(origins: "*", headers: "*", methods: "*")]

Ustaw dozwolone metody HTTP

Parametr Methods atrybutu [EnableCors] określa, które metody http mogą uzyskać dostęp do zasobu. Aby zezwolić na wszystkie metody, Użyj symbolu wieloznacznego " * ". Poniższy przykład umożliwia tylko żądania GET i POST.

[EnableCors(origins: "http://www.example.com", headers: "*", methods: "get,post")]
public class TestController : ApiController
{
    public HttpResponseMessage Get() { ... }
    public HttpResponseMessage Post() { ... }
    public HttpResponseMessage Put() { ... }    
}

Ustaw nagłówki dozwolonych żądań

W tym artykule opisano wcześniej, jak żądanie wstępnego lotu może zawierać nagłówek Access-Control-Request-Heads, zawierający listę nagłówków HTTP ustawionych przez aplikację (nazywanych dalej "nagłówkami żądań autorów"). Parametr Heads atrybutu [EnableCors] określa, które nagłówki żądań autora są dozwolone. Aby zezwolić na nagłówki, ustaw nagłówki na " * ". Aby zezwolić na określone nagłówki, ustaw nagłówki na rozdzielaną przecinkami listą dozwolonych nagłówków:

[EnableCors(origins: "http://example.com", 
    headers: "accept,content-type,origin,x-my-header", methods: "*")]

Jednak przeglądarki nie są w pełni spójne w sposobie ustawiania dostępu-nagłówka-żądania-nagłówków. Na przykład program Chrome obecnie zawiera "Źródło". FireFox nie zawiera standardowych nagłówków, takich jak "Akceptuj", nawet gdy aplikacja ustawia je w skrypcie.

Jeśli ustawisz nagłówki jako elementy inne niż " * ", należy uwzględnić co najmniej "Akceptuj", "Content-Type" i "Origin" oraz wszystkie niestandardowe nagłówki, które mają być obsługiwane.

Ustaw nagłówki dozwolonych odpowiedzi

Domyślnie przeglądarka nie uwidacznia wszystkich nagłówków odpowiedzi dla aplikacji. Domyślnie dostępne są nagłówki odpowiedzi:

  • Cache-Control
  • Content-Language
  • Content-Type
  • Wygasa
  • Last-Modified
  • Pragm

Specyfikacja CORS wywołuje te proste nagłówki odpowiedzi. Aby udostępnić inne nagłówki dla aplikacji, ustaw parametr exposedHeaders [EnableCors].

W poniższym przykładzie Get Metoda kontrolera ustawia niestandardowy nagłówek o nazwie "X-Custom-Header". Domyślnie przeglądarka nie ujawnia tego nagłówka w żądaniu między źródłami. Aby uzyskać dostęp do nagłówka, Dołącz symbol "X-Custom-Header" w exposedHeaders.

[EnableCors(origins: "*", headers: "*", methods: "*", exposedHeaders: "X-Custom-Header")]
public class TestController : ApiController
{
    public HttpResponseMessage Get()
    {
        var resp = new HttpResponseMessage()
        {
            Content = new StringContent("GET: Test message")
        };
        resp.Headers.Add("X-Custom-Header", "hello");
        return resp;
    }
}

Przekaż poświadczenia w żądaniach między źródłami

Poświadczenia wymagają specjalnej obsługi w żądaniu CORS. Domyślnie przeglądarka nie wysyła żadnych poświadczeń z żądaniem między źródłami. Poświadczenia obejmują pliki cookie oraz schematy uwierzytelniania HTTP. Aby wysłać poświadczenia z żądaniem między źródłami, klient musi ustawić atrybut XMLHttpRequest. withCredentials na wartość true.

Bezpośrednie używanie elementu XMLHttpRequest :

var xhr = new XMLHttpRequest();
xhr.open('get', 'http://www.example.com/api/test');
xhr.withCredentials = true;

W platformie jQuery:

$.ajax({
    type: 'get',
    url: 'http://www.example.com/api/test',
    xhrFields: {
        withCredentials: true
    }

Ponadto serwer musi zezwalać na poświadczenia. Aby zezwolić na poświadczenia między źródłami w interfejsie API sieci Web, ustaw właściwość SupportsCredentials na wartość true w atrybucie [EnableCors] :

[EnableCors(origins: "http://myclient.azurewebsites.net", headers: "*", 
    methods: "*", SupportsCredentials = true)]

Jeśli ta właściwość ma wartość true, odpowiedź HTTP będzie zawierać nagłówek Access-Control-Allow-Credentials. Ten nagłówek nakazuje przeglądarce, że serwer zezwala na poświadczenia dla żądania między źródłami.

Jeśli przeglądarka wysyła poświadczenia, ale odpowiedź nie zawiera prawidłowego nagłówka Access-Control-Allow-Credentials, przeglądarka nie udostępni odpowiedzi aplikacji, a żądanie AJAX zakończy się niepowodzeniem.

Należy zachować ostrożność w przypadku ustawienia SupportsCredentials na true, ponieważ oznacza to, że witryna sieci Web w innej domenie może wysyłać poświadczenia zalogowanego użytkownika do internetowego interfejsu API w imieniu użytkownika, bez wiedzy użytkownika. Specyfikacja CORS określa również, że źródła ustawień " * " są nieprawidłowe, jeśli SupportsCredentials ma wartość true.

Niestandardowi dostawcy zasad CORS

Atrybut [EnableCors] implementuje interfejs ICorsPolicyProvider . Aby zapewnić własną implementację, można utworzyć klasę, która pochodzi od atrybutu i implementuje ICorsPolicyProvider.

[AttributeUsage(AttributeTargets.Method | AttributeTargets.Class, AllowMultiple = false)]
public class MyCorsPolicyAttribute : Attribute, ICorsPolicyProvider 
{
    private CorsPolicy _policy;

    public MyCorsPolicyAttribute()
    {
        // Create a CORS policy.
        _policy = new CorsPolicy
        {
            AllowAnyMethod = true,
            AllowAnyHeader = true
        };

        // Add allowed origins.
        _policy.Origins.Add("http://myclient.azurewebsites.net");
        _policy.Origins.Add("http://www.contoso.com");
    }

    public Task<CorsPolicy> GetCorsPolicyAsync(HttpRequestMessage request)
    {
        return Task.FromResult(_policy);
    }
}

Teraz można zastosować atrybut, który można umieścić w dowolnym miejscu [EnableCors].

[MyCorsPolicy]
public class TestController : ApiController
{
    .. //

Na przykład niestandardowy dostawca zasad CORS może odczytać ustawienia z pliku konfiguracyjnego.

Zamiast używać atrybutów, można zarejestrować obiekt ICorsPolicyProviderFactory , który tworzy obiekty ICorsPolicyProvider .

public class CorsPolicyFactory : ICorsPolicyProviderFactory
{
    ICorsPolicyProvider _provider = new MyCorsPolicyProvider();

    public ICorsPolicyProvider GetCorsPolicyProvider(HttpRequestMessage request)
    {
        return _provider;
    }
}

Aby ustawić ICorsPolicyProviderFactory, wywołaj metodę rozszerzenia SetCorsPolicyProviderFactory przy uruchamianiu w następujący sposób:

public static class WebApiConfig
{
    public static void Register(HttpConfiguration config)
    {
        config.SetCorsPolicyProviderFactory(new CorsPolicyFactory());
        config.EnableCors();

        // ...
    }
}

Obsługa przeglądarki

Pakiet CORS interfejsu API sieci Web jest technologią po stronie serwera. Przeglądarka użytkownika wymaga również obsługi mechanizmu CORS. Na szczęście bieżące wersje wszystkich głównych przeglądarek obejmują obsługę mechanizmu CORS.