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

Artykuł
07/13/2023

Przez Mike Wasson

Ta zawartość jest przeznaczona dla poprzedniej wersji platformy .NET. Nowe programowanie powinno używać 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śliwej witrynie odczytywanie poufnych danych z innej witryny. Czasami jednak warto zezwolić innym witrynom na wywoływanie internetowego interfejsu API.

Współużytkowanie zasobów między źródłami (CORS) to standard W3C, który umożliwia serwerowi złagodzenie zasad tego samego źródła. Za pomocą mechanizmu CORS serwer może jawnie zezwalać 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 internetowego interfejsu API.

Oprogramowanie używane w samouczku

Program Visual Studio
Internetowy interfejs API 2.2

Wprowadzenie

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

Pokazuje usługę internetową i klienta internetowego

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

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

Te dwa adresy URL mają takie samo źródło:

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

Uwaga

Program Internet Explorer nie uwzględnia portu podczas porównywania źródeł.

Tworzenie projektu WebService

Uwaga

W tej sekcji założono, że wiesz już, jak tworzyć projekty internetowego interfejsu API. Jeśli nie, zobacz Wprowadzenie za pomocą internetowego interfejsu API ASP.NET.

Uruchom program Visual Studio i utwórz nowy projekt aplikacji internetowej ASP.NET (.NET Framework).
W oknie dialogowym Nowa aplikacja internetowa ASP.NET wybierz szablon Pusty projekt. W obszarze Dodaj foldery i odwołania podstawowe dla wybierz pole wyboru Internetowy interfejs API .

Dodaj kontroler internetowego interfejsu API o nazwie TestController z następującym kodem:

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")
            };
        }
    }
}

Aplikację można uruchomić lokalnie lub wdrożyć na platformie Azure. (Na potrzeby zrzutów ekranu w tym samouczku aplikacja jest wdrażana w Azure App Service Web Apps). Aby sprawdzić, czy internetowy interfejs API działa, przejdź do http://hostname/api/test/adresu , gdzie nazwa hosta to domena, w której wdrożono aplikację. Powinien zostać wyświetlony tekst odpowiedzi "GET: Komunikat testowy".

Tworzenie projektu WebClient

Utwórz inny projekt aplikacji internetowej ASP.NET (.NET Framework) i wybierz szablon projektu MVC. Opcjonalnie wybierz pozycję Zmień uwierzytelnianiebez uwierzytelniania>. Na potrzeby tego samouczka nie potrzebujesz uwierzytelniania.

W Eksplorator rozwiązań otwórz plik Views/Home/Index.cshtml. Zastąp kod w tym pliku następującym kodem:

<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>
}

W przypadku zmiennej serviceUrl użyj identyfikatora URI aplikacji WebService.

Uruchom aplikację WebClient lokalnie lub opublikuj ją w innej witrynie internetowej.

Po kliknięciu przycisku "Wypróbuj" żądanie AJAX zostanie przesłane do aplikacji WebService przy użyciu metody HTTP wymienionej w polu listy rozwijanej (GET, POST lub PUT). Umożliwia to analizowanie różnych żądań między źródłami. Obecnie aplikacja WebService nie obsługuje mechanizmu CORS, więc jeśli klikniesz przycisk, zostanie wyświetlony błąd.

Błąd

Uwaga

Jeśli watch ruchu HTTP w narzędziu takim jak Fiddler, zobaczysz, że przeglądarka wysyła żądanie GET, a żądanie zakończy się powodzeniem, ale wywołanie AJAX zwróci błąd. Ważne jest, aby zrozumieć, że zasady tego samego źródła nie uniemożliwiają wysyłania żądania przez przeglądarkę. Zamiast tego uniemożliwia aplikacji wyświetlanie odpowiedzi.

Debuger internetowy programu Fiddler przedstawiający żądania internetowe

Włączanie mechanizmu CORS

Teraz włączmy mechanizm CORS w aplikacji WebService. Najpierw dodaj pakiet NuGet CORS. W programie Visual Studio z 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 podstawowe biblioteki internetowego interfejsu API. Użyj flagi, -Version aby zastosować określoną wersję. Pakiet CORS wymaga internetowego interfejsu API 2.0 lub nowszego.

Otwórz plik App_Start/WebApiConfig.cs. 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. Dzięki temu żądania między źródłami z elementu WebClient nadal nie zezwalają na wszystkie inne żądania między domenami. Później opiszę parametry [ EnableCors] bardziej szczegółowo.

Nie dołączaj ukośnika do przodu na końcu adresu URL pochodzenia .

Ponownie wdróż zaktualizowaną aplikację WebService. Nie musisz aktualizować elementu WebClient. Teraz żądanie AJAX z elementu WebClient powinno zakończyć się powodzeniem. Wszystkie metody GET, PUT i POST są dozwolone.

Przeglądarka sieci Web z komunikatem o pomyślnym przetestowaniu

Jak działa mechanizm CORS

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

Specyfikacja MECHANIZMU CORS wprowadza 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ń między źródłami; Nie musisz wykonywać żadnych specjalnych czynności w kodzie JavaScript.

Oto przykład żądania między źródłami. Nagłówek "Origin" udostępnia domenę witryny, która wysyła żądanie.

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łówka Origin lub jest wartością symbolu wieloznakowego "*", co oznacza, że dowolne źródło jest 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 szczególności przeglądarka nie zezwala na żądanie. Nawet jeśli serwer zwróci pomyślną odpowiedź, przeglądarka nie udostępni odpowiedzi aplikacji klienckiej.

Żądania wstępne

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

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

Metoda żądania to GET, HEAD lub POST i
Aplikacja nie ustawia żadnych nagłówków żądań innych niż Accept, Accept-Language, Content-Language, Content-Type lub Last-Event-ID oraz
Nagłówek Content-Type (jeśli ustawiono) jest jednym z następujących elementów:
- application/x-www-form-urlencoded
- multipart/form-data
- tekst/zwykły

Reguła dotycząca nagłówków żądań dotyczy nagłówków ustawianych przez aplikację przez wywołanie setRequestHeader w obiekcie XMLHttpRequest . (Specyfikacja MECHANIZMU CORS wywołuje te "nagłówki żądań autora". Reguła nie ma zastosowania do nagłówków, które przeglądarka może ustawić, na przykład 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 wstępne 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-Headers: lista nagłówków żądań ustawionych przez aplikację na rzeczywistym żądaniu. (Ponownie nie zawiera to nagłówków, które ustawia przeglądarka).

Oto przykładowa odpowiedź 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 zawierający listę dozwolonych metod oraz opcjonalnie nagłówek Access-Control-Allow-Headers, który zawiera listę dozwolonych nagłówków. Jeśli żądanie wstępne zakończy się pomyślnie, przeglądarka wyśle rzeczywiste żądanie zgodnie z wcześniejszym opisem.

Narzędzia często używane do testowania punktów końcowych za pomocą żądań OPCJI wstępnych (na przykład Fiddler i Postman) nie wysyłają domyślnie wymaganych nagłówków OPTIONS. Upewnij się, że Access-Control-Request-Method nagłówki i Access-Control-Request-Headers są wysyłane z żądaniem, a nagłówki OPTIONS docierają do aplikacji za pośrednictwem usług IIS.

Aby skonfigurować usługi IIS w celu umożliwienia aplikacji ASP.NET odbierania żądań OPCJI i obsługi ich, 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 programu OPTIONSVerbHandler uniemożliwia usługom IIS obsługę żądań OPTIONS. Zamiana umożliwia żądaniom OPTIONS dotarcie do aplikacji, ponieważ domyślna rejestracja modułu ExtensionlessUrlHandler-Integrated-4.0 zezwala tylko na żądania GET, HEAD, POST i DEBUG z adresami URL bez rozszerzenia.

Reguły zakresu dla elementu [EnableCors]

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

Na akcję

Aby włączyć mechanizm CORS dla pojedynczej akcji, ustaw atrybut [EnableCors] w metodzie akcji. Poniższy przykład włącza mechanizm CORS tylko dla GetItem 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

W przypadku ustawienia parametru [EnableCors] w klasie kontrolera ma zastosowanie do wszystkich akcji na kontrolerze. Aby wyłączyć mechanizm CORS dla akcji, dodaj atrybut [DisableCors] do akcji. Poniższy przykład umożliwia mechanizm 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 internetowego interfejsu API w aplikacji, przekaż 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 atrybut zostanie ustawiony w więcej niż jednym zakresie, kolejność pierwszeństwa to:

Akcja
Kontroler
Globalnie

Ustawianie dozwolonych źródeł

Parametr origins atrybutu [EnableCors] określa, które źródła mogą uzyskiwać 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żesz również użyć wartości wieloznacznych "*", aby zezwolić na żądania z dowolnych źródeł.

Przed zezwoleniem na żądania z dowolnego źródła należy dokładnie rozważyć. Oznacza to, że dosłownie każda witryna internetowa może wykonywać wywołania AJAX do internetowego interfejsu API.

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

Ustawianie dozwolonych metod HTTP

Parametr metody atrybutu [EnableCors] określa, które metody HTTP mogą uzyskiwać dostęp do zasobu. Aby zezwolić na wszystkie metody, użyj wartości wieloznacznych "*". 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() { ... }    
}

Ustawianie dozwolonych nagłówków żądań

W tym artykule opisano wcześniej sposób, w jaki żądanie wstępne może zawierać nagłówek Access-Control-Request-Headers z listą nagłówków HTTP ustawionych przez aplikację (tzw. nagłówki "author request headers"). Parametr nagłówków atrybutu [EnableCors] określa, które nagłówki żądań autora są dozwolone. Aby zezwolić na wszystkie 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ą całkowicie spójne w sposobie ustawiania nagłówków Access-Control-Request-Headers. Na przykład przeglądarka Chrome obecnie zawiera "źródło". Aplikacja FireFox nie zawiera standardowych nagłówków, takich jak "Akceptuj", nawet gdy aplikacja ustawia je w skrycie.

Jeśli ustawisz nagłówki na inne niż "*", należy uwzględnić co najmniej "accept", "content-type" i "origin" oraz wszelkie nagłówki niestandardowe, które chcesz obsługiwać.

Ustawianie dozwolonych nagłówków odpowiedzi

Domyślnie przeglądarka nie uwidacznia wszystkich nagłówków odpowiedzi do aplikacji. Nagłówki odpowiedzi, które są domyślnie dostępne, to:

Cache-Control
Content-Language
Content-Type
Wygasa
Last-Modified
Pragmy

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

W poniższym przykładzie metoda kontrolera Get ustawia niestandardowy nagłówek o nazwie "X-Custom-Header". Domyślnie przeglądarka nie uwidacznia tego nagłówka w żądaniu między źródłami. Aby udostępnić nagłówek, dołącz "X-Custom-Header" w uwidocznionychHeaders.

[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;
    }
}

Przekazywanie poświadczeń 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, a także schematy uwierzytelniania HTTP. Aby wysłać poświadczenia za pomocą żądania między źródłami, klient musi ustawić wartość XMLHttpRequest.withCredentials na wartość true.

Bezpośrednie używanie funkcji XMLHttpRequest :

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

W trybie 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 internetowym interfejsie API, 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 informuje przeglądarkę, że serwer zezwala na poświadczenia dla żądania między źródłami.

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

Należy zachować ostrożność podczas ustawiania wartości SupportsCredentials na wartość true, ponieważ oznacza to, że witryna internetowa w innej domenie może wysyłać poświadczenia zalogowanego użytkownika do internetowego interfejsu API w imieniu użytkownika bez świadomości użytkownika. Specyfikacja MECHANIZMU CORS określa również, że ustawienie źródła na wartość "*" jest nieprawidłowe, jeśli wartość SupportsCredentials ma wartość true.

Niestandardowi dostawcy zasad CORS

Atrybut [EnableCors] implementuje interfejs ICorsPolicyProvider . Możesz zapewnić własną implementację, tworząc klasę pochodzącą z atrybutu i implementując element 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żesz zastosować atrybut dowolnego miejsca, które należy umieścić [EnableCors].

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

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

Alternatywą dla używania atrybutów jest zarejestrowanie obiektu ICorsPolicyProviderFactory , który tworzy obiekty ICorsPolicyProvider .

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

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

Aby ustawić metodę ICorsPolicyProviderFactory, wywołaj metodę rozszerzenia SetCorsPolicyProviderFactory podczas uruchamiania 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 to technologia po stronie serwera. Przeglądarka użytkownika musi również obsługiwać mechanizm CORS. Na szczęście bieżące wersje wszystkich głównych przeglądarek obejmują obsługę mechanizmu CORS.

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

Oprogramowanie używane w samouczku

Wprowadzenie

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

Tworzenie projektu WebService

Tworzenie projektu WebClient

Włączanie mechanizmu CORS

Jak działa mechanizm CORS

Reguły zakresu dla elementu [EnableCors]

Ustawianie dozwolonych źródeł

Ustawianie dozwolonych metod HTTP

Ustawianie dozwolonych nagłówków żądań

Ustawianie dozwolonych nagłówków odpowiedzi

Przekazywanie poświadczeń w żądaniach między źródłami

Niestandardowi dostawcy zasad CORS

Obsługa przeglądarki

Opinia

Opinia

Dodatkowe zasoby