Obsługa udostępniania zasobów między źródłami (CORS) dla usługi Azure Storage

Począwszy od wersji 2013-08-15, usługi Azure Storage obsługują współużytkowanie zasobów między źródłami (CORS) dla usług obiektów blob, tabel i kolejek. Usługa plików obsługuje cors począwszy od wersji 2015-02-21.

Mechanizm CORS (udostępnianie zasobów między źródłami) to funkcja protokołu HTTP, która umożliwia aplikacji internetowej działającej w ramach jednej domeny dostęp do zasobów w innej domenie. Przeglądarki internetowe implementują ograniczenie zabezpieczeń znane jako zasady tego samego źródła, które uniemożliwiają stronie internetowej wywoływanie interfejsów API w innej domenie; CorS zapewnia bezpieczny sposób zezwalania jednej domenie (domenie pochodzenia) na wywołanie interfejsów API w innej domenie. Zobacz specyfikację CORS, aby uzyskać szczegółowe informacje na temat specyfikacji CORS.

Reguły CORS można ustawić osobno dla każdej z usług Azure Storage, wywołując wywołania Ustaw właściwości usługi Blob Service,Ustaw właściwości usługi plików,Ustaw właściwości usługi kolejki i Ustaw właściwości usługi tabel. Po ustawieniu reguł CORS dla usługi prawidłowo uwierzytelnione żądanie przesłane do usługi z innej domeny zostanie ocenione, aby określić, czy jest ono dozwolone zgodnie z określonymi regułami.

Ważne

Mechanizm CORS nie jest mechanizmem autoryzacji. Każde żądanie wykonane względem zasobu magazynu, gdy jest włączona funkcja CORS, musi mieć prawidłowy nagłówek autoryzacji lub musi być wykonane względem zasobu publicznego.

CorS jest obsługiwany dla wszystkich typów kont magazynu z wyjątkiem kont magazynu ogólnego przeznaczenia w wersji 1 lub 2 w warstwie wydajności Premium.

Opis żądań CORS

Żądanie CORS z domeny źródła może składać się z dwóch oddzielnych żądań:

  • Żądanie wstępne, które wysyła zapytanie do ograniczeń CORS narzuconych przez usługę. Żądanie wstępne jest wymagane, chyba że metoda żądania jest prostąmetodą , czyli GET, HEAD lub POST.

  • Rzeczywiste żądanie wykonane względem żądanego zasobu.

Żądanie wstępne

Żądanie wstępne wysyła zapytanie do ograniczeń CORS, które zostały ustanowione dla usługi magazynu przez właściciela konta. Przeglądarka internetowa (lub inny agent użytkownika) wysyła żądanie OPTIONS, które zawiera nagłówki żądania, metodę i domenę źródła. Usługa magazynu ocenia zamierzony proces na podstawie wstępnie skonfigurowanego zestawu reguł CORS, które określają, które domeny źródła, metody żądań i nagłówki żądań mogą być określone dla rzeczywistego żądania względem zasobu magazynu.

Jeśli dla usługi jest włączona reguła CORS, która pasuje do żądania wstępnego, usługa odpowiada kodem stanu 200 (OK) i zawiera wymagane nagłówki Access-Control w odpowiedzi.

Jeśli dla usługi nie włączono reguł CORS lub żadna reguła CORS nie pasuje do żądania wstępnego, usługa odpowie kodem stanu 403 (Zabronione).

Jeśli żądanie OPTIONS nie zawiera wymaganych nagłówków CORS (nagłówków Origin i Access-Control-Request-Method), usługa odpowie kodem stanu 400 (Złe żądanie).

Należy pamiętać, że żądanie wstępne jest oceniane względem usługi (obiekt blob, plik, kolejka lub tabela), a nie względem żądanego zasobu. Aby żądanie zakończyło się pomyślnie, właściciel konta musi włączyć obsługę cors w ramach właściwości usługi konta.

Rzeczywiste żądanie

Po zaakceptowaniu żądania wstępnego i zwróceniu odpowiedzi przeglądarka wysyła rzeczywiste żądanie do zasobu magazynu. Przeglądarka natychmiast odmówi rzeczywistego żądania, jeśli żądanie wstępne zostanie odrzucone.

Rzeczywiste żądanie jest traktowane jako normalne żądanie względem usługi magazynu. Obecność nagłówka Origin wskazuje, że żądanie jest żądaniem CORS, a usługa sprawdzi pasujące reguły CORS. Jeśli dopasowanie zostanie znalezione, nagłówki Access-Control zostaną dodane do odpowiedzi i wysłane z powrotem do klienta. Jeśli dopasowanie nie zostanie znalezione, nagłówki Access-Control CORS nie zostaną zwrócone.

Włączanie cors dla usługi Azure Storage

Reguły CORS są ustawiane na poziomie usługi, dlatego należy włączyć lub wyłączyć zasady CORS dla każdej usługi (obiekt blob, plik, kolejka i tabela) oddzielnie. Domyślnie mechanizm CORS jest wyłączony dla każdej usługi. Aby włączyć cors, należy ustawić odpowiednie właściwości usługi przy użyciu wersji 2013-08-15 lub nowszej dla usług obiektów blob, kolejek i tabel, wersji 2015-02-21 lub usługi plików. Aby włączyć obsługę cors, dodaj reguły CORS do właściwości usługi. Aby uzyskać szczegółowe informacje o tym, jak włączyć lub wyłączyć funkcję CORS dla usługi i jak ustawić reguły CORS, zapoznaj się z tematami Ustawianie właściwości usługi blob,Ustawianie właściwości usługi plików,Ustawianie właściwości usługi tabel i Ustawianie właściwości usługi kolejki.

Oto przykład pojedynczej reguły CORS określonej za pośrednictwem Set Service Properties operacji:

<Cors>
    <CorsRule>  
        <AllowedOrigins>http://www.contoso.com, http://www.fabrikam.com</AllowedOrigins>  
        <AllowedMethods>PUT,GET</AllowedMethods>  
        <AllowedHeaders>x-ms-meta-data*,x-ms-meta-target*,x-ms-meta-abc</AllowedHeaders>  
        <ExposedHeaders>x-ms-meta-*</ExposedHeaders>  
        <MaxAgeInSeconds>200</MaxAgeInSeconds>  
    </CorsRule>  
<Cors>  
  

Poniżej opisano każdy element uwzględniony w regułę CORS:

  • AllowedOrigins: domeny pochodzenia, które mogą żądać usługi magazynu za pośrednictwem cors. Domena źródła to domena, z której pochodzi żądanie. Należy pamiętać, że źródło musi być dokładnym dopasowaniem z rozróżnianą wielkością liter do źródła wysyłanego do usługi przez wiek użytkownika. Można również użyć symbolu wieloznacznego "*", aby zezwolić wszystkim domenom pochodzenia na żądania za pośrednictwem cors. W powyższym przykładzie domeny i http://www.contoso.com mogą żądania względem usługi przy użyciu http://www.fabrikam.com cors.

  • AllowedMethods: metody (czasowniki żądania HTTP), których domena pochodzenia może używać na użytek żądania CORS. W powyższym przykładzie są dozwolone jedynie żądania PUT i GET.

  • AllowedHeaders: nagłówki żądania, które domena źródła może określić w żądaniu CORS. W powyższym przykładzie dozwolone są wszystkie nagłówki metadanych rozpoczynające się od x-ms-meta-data x-ms-meta-target , i x-ms-meta-abc . Należy pamiętać, że symbol wieloznaczny "*" wskazuje, że każdy nagłówek rozpoczynający się od określonego prefiksu jest dozwolony.

  • ExposedHeaders: nagłówki odpowiedzi, które mogą być wysyłane w odpowiedzi na żądanie CORS i udostępniane przez przeglądarkę wystawcy żądania. W powyższym przykładzie przeglądarka jest instrukcjeem uwidocznić dowolny nagłówek rozpoczynający się od x-ms-meta .

  • MaxAgeInSeconds: maksymalny czas buforowania żądania wstępnego OPTIONS przez przeglądarkę.

Usługi Azure Storage obsługują określanie nagłówków z prefiksami dla elementów AllowedHeaders i ExposedHeaders. Aby zezwolić na kategorię nagłówków, można określić wspólny prefiks dla tej kategorii. Na przykład określenie jako nagłówka z prefiksem określa regułę, która będzie odpowiadać wszystkim x-ms-meta* nagłówkom, które zaczynają się od x-ms-meta .

Następujące ograniczenia dotyczą reguł CORS:

  • Można określić maksymalnie pięć reguł CORS na usługę magazynu (blob, file, table i queue).

  • Maksymalny rozmiar wszystkich ustawień reguł CORS w żądaniu, z wyjątkiem tagów XML, nie powinien przekraczać 2 KiB.

  • Długość dozwolonego nagłówka, ujawnionego nagłówka lub dozwolonego źródła nie powinna przekraczać 256 znaków.

  • Dozwolone nagłówki i widoczne nagłówki mogą być:

    • Nagłówki literału, w których podano dokładną nazwę nagłówka, takie jak x-ms-meta-processed. W żądaniu można określić maksymalnie 64 nagłówki literałów.
    • Nagłówki z prefiksem, w których podano prefiks nagłówka, na przykład x-ms-meta-data *. Określenie prefiksu w ten sposób umożliwia lub uwidacznia dowolny nagłówek, który zaczyna się od danego prefiksu. W żądaniu można określić maksymalnie dwa nagłówki z prefiksem.
  • Metody (lub czasowniki HTTP) określone w elemencie AllowedMethods muszą być zgodne z metodami obsługiwanymi przez interfejsy API usługi Azure Storage. Obsługiwane metody to DELETE, GET, HEAD, MERGE, POST, PATCH, OPTIONS i PUT.

Opis logiki oceny reguł CORS

Gdy usługa magazynu odbiera żądanie wstępne lub rzeczywiste, ocenia to żądanie na podstawie reguł CORS ustanowionych dla usługi za pośrednictwem odpowiedniej operacji Ustaw właściwości usługi. Reguły CORS są oceniane w kolejności, w jakiej zostały ustawione w treści żądania operacji Ustaw właściwości usługi.

Reguły CORS są oceniane w następujący sposób:

  1. Najpierw sprawdzana jest domena źródła żądania względem domen wymienionych dla AllowedOrigins elementu . Jeśli domena źródła znajduje się na liście lub wszystkie domeny są dozwolone ze znakiem wieloznacznych "*", ocena reguł będzie kontynuowana. Jeśli domena źródła nie zostanie uwzględniona, żądanie zakończy się niepowodzeniem.

  2. Następnie metoda (lub czasownik HTTP) żądania jest sprawdzana względem metod wymienionych w AllowedMethods elemencie . Jeśli metoda znajduje się na liście, będzie kontynuowana ocena reguł. Jeśli nie, żądanie zakończy się niepowodzeniem.

  3. Jeśli żądanie pasuje do reguły w domenie pochodzenia i jej metodzie, ta reguła jest wybierana w celu przetwarzania żądania i żadne dalsze reguły nie są oceniane. Jednak zanim żądanie zakończy się powodzeniem, wszystkie nagłówki określone w żądaniu są sprawdzane względem nagłówków wymienionych w AllowedHeaders elemencie . Jeśli wysłane nagłówki nie są zgodne z dozwolonymi nagłówkami, żądanie kończy się niepowodzeniem.

Ponieważ reguły są przetwarzane w kolejności, w których znajdują się w treści żądania, najlepsze rozwiązania zalecają określenie najbardziej restrykcyjnych reguł w odniesieniu do źródeł w pierwszej kolejności na liście, aby były one oceniane jako pierwsze. Określ reguły, które są mniej restrykcyjne — na przykład regułę zezwalania na wszystkie źródła — na końcu listy.

Przykład — ocena reguł CORS

Poniższy przykład przedstawia częściową treść żądania dla operacji w celu ustawienia reguł CORS dla usług magazynu. Aby uzyskać szczegółowe informacje na temat konstruowania żądania,zobacz Ustawianie właściwości usługi Blob Service,Ustawianie właściwości usługi plików,Ustawianie właściwości usługi kolejki i Ustawianie właściwości usługi tabel.

<Cors>  
    <CorsRule>  
        <AllowedOrigins>http://www.contoso.com</AllowedOrigins>  
        <AllowedMethods>PUT,HEAD</AllowedMethods>  
        <MaxAgeInSeconds>5</MaxAgeInSeconds>  
        <ExposedHeaders>x-ms-*</ExposedHeaders>  
        <AllowedHeaders>x-ms-blob-content-type, x-ms-blob-content-disposition</AllowedHeaders>  
    </CorsRule>  
    <CorsRule>  
        <AllowedOrigins>*</AllowedOrigins>  
        <AllowedMethods>PUT,GET</AllowedMethods>  
        <MaxAgeInSeconds>5</MaxAgeInSeconds>  
        <ExposedHeaders>x-ms-*</ExposedHeaders>  
        <AllowedHeaders>x-ms-blob-content-type, x-ms-blob-content-disposition</AllowedHeaders>  
    </CorsRule>  
    <CorsRule>  
        <AllowedOrigins>http://www.contoso.com</AllowedOrigins>  
        <AllowedMethods>GET</AllowedMethods>  
        <MaxAgeInSeconds>5</MaxAgeInSeconds>  
        <ExposedHeaders>x-ms-*</ExposedHeaders>  
        <AllowedHeaders>x-ms-client-request-id</AllowedHeaders>  
    </CorsRule>  
</Cors>

Następnie rozważ następujące żądania CORS:

Metoda Origin Nagłówki żądań Dopasowanie reguły Wynik
PUT http://www.contoso.com x-ms-blob-content-type Pierwsza reguła Powodzenie
Pobierz http://www.contoso.com x-ms-blob-content-type Druga reguła Powodzenie
Pobierz http://www.contoso.com x-ms-client-request-id Druga reguła Niepowodzenie

Pierwsze żądanie jest takie, jak pierwsza reguła — domena pochodzenia pasuje do dozwolonych źródeł, metoda pasuje do dozwolonych metod, a nagłówek pasuje do dozwolonych nagłówków — i tak się powiedzie.

Drugie żądanie nie jest zgodne z pierwszą regułą, ponieważ metoda nie jest dopasowana do dozwolonych metod. Jest jednak zgodne z drugą regułą, więc się powiedzie.

Trzecie żądanie pasuje do drugiej reguły w jej domenie pochodzenia i metodzie, więc żadne dalsze reguły nie są oceniane. Jednak nagłówek nie jest dozwolony przez drugą regułę, więc żądanie kończy się niepowodzeniem, mimo że semantyka trzeciej reguły pozwoliłaby na x-ms-client-request-id powodzenie.

Uwaga

Mimo że w tym przykładzie przedstawiono mniej restrykcyjną regułę przed bardziej restrykcyjną regułą, ogólnie rzecz biorąc, najlepszym rozwiązaniem jest najpierw lista najbardziej restrykcyjnych reguł.

Opis sposobu ustawienia nagłówka Vary

Nagłówek jest standardowym nagłówkiem HTTP/1.1 składającym się z zestawu pól nagłówka żądania, które doradzają przeglądarce lub agentowi użytkownika dotyczące kryteriów wybranych przez serwer w celu przetwarzania Vary żądania. Nagłówek jest używany głównie do buforowania przez proxy, przeglądarki i sieci CDN, które używają go do określenia sposobu Vary buforowania odpowiedzi. Aby uzyskać szczegółowe informacje, zobacz specyfikację nagłówka Vary.

Gdy przeglądarka lub inny agent użytkownika buforuje odpowiedź z żądania CORS, domena źródła jest buforowana jako dozwolone źródło. Gdy druga domena wydaje to samo żądanie dotyczące zasobu magazynu, gdy pamięć podręczna jest aktywna, agent użytkownika pobiera buforowane domeny pochodzenia. Druga domena nie odpowiada domenie buforowanej, więc żądanie kończy się niepowodzeniem, jeśli w przeciwnym razie zakończy się pomyślnie. W niektórych przypadkach usługa Azure Storage ustawia nagłówek na , aby poinstruować agenta użytkownika, aby wysyłał kolejne żądanie CORS do usługi, gdy domena żądania różni się od źródła w pamięci Vary Origin podręcznej.

Usługa Azure Storage ustawia Vary nagłówek na dla Origin rzeczywistych żądań GET/HEAD w następujących przypadkach:

  • Gdy źródło żądania dokładnie pasuje do dozwolonego źródła zdefiniowanego przez regułę CORS. Aby dokładnie dopasować element, reguła CORS może nie zawierać symbolu wieloznacznego "*".

  • Nie ma reguły pasującej do źródła żądania, ale dla usługi magazynu jest włączona funkcja CORS.

Jeśli żądanie GET/HEAD pasuje do reguły CORS, która zezwala na wszystkie źródła, odpowiedź wskazuje, że wszystkie źródła są dozwolone, a pamięć podręczna agenta użytkownika będzie zezwalać na kolejne żądania z dowolnej domeny pochodzenia, gdy pamięć podręczna jest aktywna.

Należy pamiętać, że w przypadku żądań korzystających z metod innych niż GET/HEAD usługi magazynu nie ustawią nagłówka, ponieważ odpowiedzi na te metody nie są buforowane przez Vary agentów użytkownika.

W poniższej tabeli przedstawiono sposób, w jaki usługa Azure Storage będzie odpowiadać na żądania GET/HEAD na podstawie wcześniej wymienionych przypadków:

Nagłówek źródła obecny w żądaniu Reguły CORS określone dla tej usługi Istnieje reguła dopasowywania, która zezwala na wszystkie źródła ( * ) Istnieje reguła dopasowywania dla dokładnego dopasowania źródła Odpowiedź zawiera nagłówek Vary ustawiony na Źródło Odpowiedź obejmuje access-control-allowed-origin: " * " Odpowiedź obejmuje nagłówki Access-Control-Exposed-Header
Nie Nie Nie Nie Nie Nie Nie
Nie Tak Nie Nie Tak Nie Nie
Nie Tak Tak Nie Nie Tak Tak
Tak Nie Nie Nie Nie Nie Nie
Tak Tak Nie Tak Tak Nie Tak
Tak Tak Nie Nie Tak Nie Nie
Tak Tak Tak Nie Nie Tak Tak

Rozliczanie żądań CORS

Pomyślne żądania wstępne są rozliczane, jeśli włączono obsługę cors dla dowolnej z usług magazynu dla konta (przez wywołanie funkcji Ustaw właściwości usługi Blob Service,Ustaw właściwości usługi kolejki,Ustaw właściwości usługi plików lub Ustaw właściwości usługi tabel). Aby zminimalizować opłaty, rozważ ustawienie dużej wartości elementu w zasadach CORS, tak aby agent użytkownika MaxAgeInSeconds buforuje żądanie.

Nieudane żądania wstępne nie będą naliczane.

Zobacz też

Specyfikacja udostępniania zasobów między źródłami W3C