Obsługa współużytkowania zasobów między źródłami (CORS) dla usługi Azure Storage

  • Artykuł

Począwszy od wersji 2013-08-15, usługi magazynu platformy Azure obsługują współużytkowanie zasobów między źródłami (CORS) dla usług Blob, Table i Queue. Usługa plików obsługuje mechanizm 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 o tym samym pochodzeniu , które uniemożliwia stronie internetowej wywoływanie interfejsów API w innej domenie; Mechanizm CORS zapewnia bezpieczny sposób zezwalania jednej domenie (domenie pochodzenia) na wywoływanie interfejsów API w innej domenie. Zobacz specyfikację mechanizmu CORS , aby uzyskać szczegółowe informacje na temat mechanizmu CORS.

Reguły CORS można ustawić indywidualnie dla każdej z usług Azure Storage, wywołując funkcję Set Blob Service Properties (Ustaw właściwości usługi Blob Service), Set File Service Properties (Ustawianie właściwości usługi plików), Set Queue Service Properties (Ustawianie właściwości usługi Kolejki) i Set Table Service Properties (Ustawianie właściwości usługi Table Service). 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 dotyczące zasobu magazynu, gdy włączono mechanizm CORS, musi mieć prawidłowy nagłówek autoryzacji lub musi zostać wykonany względem zasobu publicznego.

Mechanizm 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 pochodzenia 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 zamierzoną operację na podstawie wstępnie skonfigurowanego zestawu reguł CORS, które określają, które domeny pochodzenia, metody żądania i nagłówki żądań mogą być określone na rzeczywistym żądaniu względem zasobu magazynu.

Jeśli mechanizm CORS jest włączony dla usługi i istnieje reguła CORS zgodna z żądaniem wstępnym, usługa odpowiada kodem stanu 200 (OK) i zawiera wymagane nagłówki Access-Control w odpowiedzi.

Jeśli mechanizm CORS nie jest włączony dla usługi 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łówki Origin i Access-Control-Request-Method), usługa odpowie kodem stanu 400 (Nieprawidłowe żądanie).

Należy pamiętać, że żądanie wstępne jest oceniane względem usługi (obiektu blob, pliku, kolejki lub tabeli), a nie względem żądanego zasobu. Właściciel konta musi włączyć mechanizm CORS, ustawiając odpowiednie właściwości usługi konta, aby żądanie zakończyło się pomyślnie.

Rzeczywiste żądanie

Po zaakceptowaniu żądania wstępnego i zwróceniu odpowiedzi przeglądarka wyśle rzeczywiste żądanie względem zasobu magazynu. Przeglądarka natychmiast odrzuci rzeczywiste żądanie, 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 zgodne reguły CORS. W przypadku znalezienia dopasowania nagłówki Access-Control są dodawane do odpowiedzi i wysyłane z powrotem do klienta. Jeśli dopasowanie nie zostanie znalezione, nagłówki CORS Access-Control nie zostaną zwrócone.

Włączanie mechanizmu CORS dla usługi Azure Storage

Reguły CORS są ustawiane na poziomie usługi, dlatego należy osobno włączyć lub wyłączyć mechanizm CORS dla każdej usługi (obiekt blob, plik, kolejka i tabela). Domyślnie mechanizm CORS jest wyłączony dla każdej usługi. Aby włączyć mechanizm CORS, należy ustawić odpowiednie właściwości usługi przy użyciu wersji 2013-08-15 lub nowszej dla usług Blob, Queue i Table albo w wersji 2015-02-21 lub dla usługi plików. Mechanizm CORS można włączyć, dodając reguły CORS do właściwości usługi. Aby uzyskać szczegółowe informacje na temat włączania lub wyłączania mechanizmu CORS dla usługi oraz ustawiania reguł CORS, zapoznaj się z tematem 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 Table Service i Ustawianie właściwości usługi kolejki.

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

<Cors>
    <CorsRule>  
        <AllowedOrigins>http://*.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>

Każdy element zawarty w regule CORS został opisany poniżej:

  • AllowedOrigins: domeny pochodzenia, które mogą wysyłać żądania do usługi magazynu za pośrednictwem mechanizmu CORS. Domena źródła to domena, z której pochodzi żądanie. Należy pamiętać, że pochodzenie musi być dokładnym dopasowaniem wielkości liter do źródła, które wiek użytkownika wysyła do usługi.

    Możesz użyć symbolu wieloznakowego "*" zamiast określonej domeny, aby umożliwić wszystkim domenom pochodzenia wykonywanie żądań za pośrednictwem mechanizmu CORS. Można również użyć symbolu wieloznacznych zamiast poddomeny, aby zezwolić na wszystkie poddomeny danej domeny na wykonywanie żądań za pośrednictwem mechanizmu CORS. W powyższym przykładzie wszystkie poddomeny contoso.com mogą wysyłać żądania za pośrednictwem mechanizmu CORS, podczas gdy tylko żądania z www poddomeny fabrikam.com elementu są dozwolone za pośrednictwem mechanizmu CORS.

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

  • AllowedHeaders: nagłówki żądań, które domena źródła może określać w żądaniu CORS. W powyższym przykładzie wszystkie nagłówki metadanych rozpoczynające się od x-ms-meta-data, x-ms-meta-targeti x-ms-meta-abc są dozwolone. 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 poinstruowana, aby uwidoczniła dowolny nagłówek rozpoczynający się od x-ms-meta.

  • MaxAgeInSeconds: maksymalny czas buforowania żądania OPTIONS w przeglądarce.

Usługi magazynu platformy Azure obsługują określanie prefiksów nagłówków dla elementów AllowedHeaders i ExposedHeaders . Aby zezwolić na kategorię nagłówków, można określić wspólny prefiks tej kategorii. Na przykład określenie x-ms-meta* jako prefiksu nagłówka ustanawia regułę, która będzie zgodna ze x-ms-metawszystkimi nagłówkami rozpoczynającymi się od .

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

  • Można określić maksymalnie pięć reguł CORS na usługę magazynu (obiekt blob, plik, tabela i kolejka).

  • Maksymalny rozmiar wszystkich ustawień reguł CORS dla żądania, z wyłączeniem tagów XML, nie powinien przekraczać 2 KiB.

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

  • Dozwolone nagłówki i uwidocznione nagłówki mogą być następujące:

    • 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łu.
    • Prefiksy nagłówków, w których podano prefiks nagłówka, taki jak x-ms-meta-data*. Określenie prefiksu w ten sposób umożliwia lub uwidacznia dowolny nagłówek rozpoczynający się od danego prefiksu. W żądaniu można określić maksymalnie dwa prefiksy nagłówków.

  • Metody (lub czasowniki HTTP) określone w elemecie 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 wstępne lub rzeczywiste żądanie, 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 której zostały ustawione w treści żądania operacji Ustawianie właściwości usługi.

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

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

  2. Następnie metoda (lub czasownik HTTP) żądania jest sprawdzana względem metod wymienionych w elemecie AllowedMethods . Jeśli metoda znajduje się na liście, ocena reguł będzie kontynuowana; 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 zostanie wybrana do przetworzenia żądania i nie zostaną ocenione żadne dalsze reguły. Zanim żądanie zakończy się pomyślnie, wszystkie nagłówki określone w żądaniu są sprawdzane względem nagłówków wymienionych w elemecie AllowedHeaders . Jeśli wysłane nagłówki nie pasują do dozwolonych nagłówków, żądanie zakończy się niepowodzeniem.

Ponieważ reguły są przetwarzane w kolejności, w której znajdują się w treści żądania, najlepsze rozwiązania zaleca określenie najbardziej restrykcyjnych reguł w odniesieniu do źródeł na liście, tak aby były one oceniane jako pierwsze. Określ reguły, które są mniej restrykcyjne — na przykład reguła zezwala 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 ustawiania reguł CORS dla usług magazynu. 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 Table Service , aby uzyskać szczegółowe informacje na temat konstruowania żądania.

<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
GET http://www.contoso.com x-ms-blob-content-type Druga reguła Powodzenie
GET http://www.contoso.com x-ms-client-request-id Druga reguła Niepowodzenie

Pierwsze żądanie jest zgodne z pierwszą regułą — domena pochodzenia jest zgodna z dozwolonymi źródłami, metoda jest zgodna z dozwolonymi metodami, 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 zgodna z dozwolonymi metodami. Jest to jednak zgodne z drugą regułą, więc się powiedzie.

Trzecie żądanie jest zgodne z drugą regułą w domenie i metodzie pochodzenia, więc nie są oceniane żadne dalsze reguły. x-ms-client-request-id Jednak nagłówek nie jest dozwolony przez drugą regułę, więc żądanie kończy się niepowodzeniem, pomimo faktu, że semantyka trzeciej reguły umożliwiłaby jej powodzenie.

Uwaga

Chociaż w tym przykładzie przedstawiono mniej restrykcyjną regułę przed bardziej restrykcyjnym, najlepszym rozwiązaniem jest najpierw wyświetlenie listy najbardziej restrykcyjnych reguł.

Informacje na temat ustawiania nagłówka Vary

Nagłówek Vary jest standardowym nagłówkiem HTTP/1.1 składającym się z zestawu pól nagłówka żądania, które informują przeglądarkę lub agenta użytkownika o kryteriach wybranych przez serwer w celu przetworzenia żądania. Nagłówek Vary jest używany głównie do buforowania przez serwery proxy, przeglądarki i sieci CDN, które używają go do określenia sposobu 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 pochodzenia jest buforowana jako dozwolone źródło. Gdy druga domena wystawia to samo żądanie zasobu magazynu, gdy pamięć podręczna jest aktywna, agent użytkownika pobiera buforowanej domeny źródła. Druga domena nie jest zgodna z domeną buforowanej, więc żądanie kończy się niepowodzeniem, gdy w przeciwnym razie powiedzie się. W niektórych przypadkach usługa Azure Storage ustawia Vary nagłówek, aby Origin polecił agentowi użytkownika wysłanie kolejnego żądania CORS do usługi, gdy domena żądająca różni się od buforowanego źródła.

Usługa Azure Storage ustawia Vary nagłówek na Origin wartość dla 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łę MECHANIZMU CORS. Aby być dokładnym dopasowaniem, reguła CORS może nie zawierać symbolu wieloznakowego "*".

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

W przypadku, gdy żą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 zezwoli 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 będą ustawiać nagłówka Vary , ponieważ odpowiedzi na te metody nie są buforowane przez agentów użytkowników.

W poniższej tabeli przedstawiono sposób reagowania usługi Azure Storage na żądania GET/HEAD w oparciu o wymienione wcześniej przypadki:

Nagłówek origin obecny na żądanie Reguły CORS określone dla tej usługi Istnieje reguła dopasowania, która zezwala na wszystkie źródła (*) Reguła dopasowania istnieje dla dokładnego dopasowania pochodzenia Odpowiedź zawiera różne nagłówki ustawione na źródło Odpowiedź obejmuje dostęp do kontroli dostępu dozwolone źródło: "*" Odpowiedź zawiera nagłówki Access-Control-Exposed-Headers
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

Rozliczenia dla żądań CORS

Pomyślne żądania wstępne są rozliczane, jeśli włączono mechanizm CORS dla dowolnego z usług magazynowania dla konta (wywołując polecenie 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 MaxAgeInSeconds elementu w regułach CORS na dużą wartość, aby agent użytkownika buforować żądanie.

Nieudane żądania wstępne nie zostaną naliczone.

Zobacz też

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