Ustawianie listy ACL kontenerów

  • Artykuł

Operacja Set Container ACL ustawia uprawnienia dla określonego kontenera. Uprawnienia wskazują, czy obiekty blob w kontenerze mogą być dostępne publicznie.

Od wersji 2009-09-19 uprawnienia kontenera zapewniają następujące opcje zarządzania dostępem do kontenera:

  • Pełny publiczny dostęp do odczytu: Dane kontenerów i obiektów blob można odczytywać za pośrednictwem żądania anonimowego. Klienci mogą wyliczać obiekty blob w kontenerze za pośrednictwem żądania anonimowego, ale nie mogą wyliczać kontenerów na koncie magazynu.

  • Publiczny dostęp do odczytu tylko dla obiektów blob: Dane obiektów blob w tym kontenerze można odczytywać za pośrednictwem żądania anonimowego, ale dane kontenera nie są dostępne. Klienci nie mogą wyliczać obiektów blob w kontenerze za pośrednictwem żądania anonimowego.

  • Brak publicznego dostępu do odczytu: Dane kontenerów i obiektów blob mogą być odczytywane tylko przez właściciela konta.

Set Container ACL Ustawia również przechowywane zasady dostępu do użycia z sygnaturami dostępu współdzielonego. Aby uzyskać więcej informacji, zobacz Definiowanie przechowywanych zasad dostępu.

Cały publiczny dostęp do kontenera jest anonimowy, podobnie jak dostęp za pośrednictwem sygnatury dostępu współdzielonego.

Żądanie

Żądanie Set Container ACL może być skonstruowane w następujący sposób. Zalecamy korzystanie z protokołu HTTPS. Zastąp ciąg myaccount nazwą konta magazynu:

Metoda Identyfikator URI żądania Wersja PROTOKOŁU HTTP
PUT https://myaccount.blob.core.windows.net/mycontainer?restype=container&comp=acl HTTP/1.1

Żądanie usługi magazynu emulowanego

Podczas wykonywania żądania względem usługi emulowanego magazynu określ nazwę hosta emulatora i port usługi Blob jako 127.0.0.1:10000, a następnie nazwę emulowanego konta magazynu:

Metoda Identyfikator URI żądania Wersja PROTOKOŁU HTTP
PUT http://127.0.0.1:10000/devstoreaccount1/mycontainer?restype=container&comp=acl HTTP/1.1

Aby uzyskać więcej informacji, zobacz Use the Azurite emulator for local Azure Storage development (Używanie emulatora Azurite do lokalnego programowania w usłudze Azure Storage).

Parametry identyfikatora URI

W identyfikatorze URI żądania można określić następujące dodatkowe parametry:

Parametr Opis
timeout Opcjonalny. Parametr jest wyrażony timeout w sekundach. Aby uzyskać więcej informacji, zobacz Ustawianie limitów czasu dla operacji usługi Blob Service.

Nagłówki żądań

Wymagane i opcjonalne nagłówki żądań zostały opisane w poniższej tabeli:

Nagłówek żądania Opis
Authorization Wymagane. Określa schemat autoryzacji, nazwę konta i podpis. Aby uzyskać więcej informacji, zobacz Autoryzowanie żądań do usługi Azure Storage.
Date lub x-ms-date Wymagane. Określa dla żądania godzinę w formacie uniwersalnego czasu koordynowanego (UTC). Aby uzyskać więcej informacji, zobacz Autoryzowanie żądań do usługi Azure Storage.
x-ms-version Opcjonalny. Określa wersję operacji do użycia dla tego żądania. Aby uzyskać więcej informacji, zobacz Przechowywanie wersji dla usług Azure Storage.
x-ms-blob-public-access Opcjonalny. Określa, czy dostęp do danych w kontenerze może być uzyskiwany publicznie i na poziomie dostępu. Możliwe wartości to:

- container: określa pełny publiczny dostęp do odczytu dla danych kontenera i obiektów blob. Klienci mogą wyliczać obiekty blob w kontenerze za pośrednictwem żądania anonimowego, ale nie mogą wyliczać kontenerów na koncie magazynu.
- blob: Określa publiczny dostęp do odczytu dla obiektów blob. Dane obiektów blob w tym kontenerze można odczytywać za pośrednictwem żądania anonimowego, ale dane kontenera nie są dostępne. Klienci nie mogą wyliczać obiektów blob w kontenerze za pośrednictwem żądania anonimowego.

Jeśli ten nagłówek nie jest uwzględniony w żądaniu, dane kontenera są prywatne dla właściciela konta.

Należy pamiętać, że ustawienie publicznego dostępu dla kontenera na koncie usługi Azure Premium Storage nie jest dozwolone.
x-ms-lease-id: <ID> Opcjonalnie, wersja 2012-02-12 lub nowsza. Jeśli jest określony, powiedzie się tylko wtedy, Set Container ACL gdy dzierżawa kontenera jest aktywna i jest zgodna z tym identyfikatorem. Jeśli nie ma aktywnej dzierżawy lub identyfikator nie jest zgodny, zwracany jest błąd 412 (Niepowodzenie warunku wstępnego).
x-ms-client-request-id Opcjonalny. Zapewnia nieprzezroczystą wartość wygenerowaną przez klienta z limitem znaków 1-kibibyte (KiB) rejestrowanym w dziennikach podczas konfigurowania rejestrowania. Zdecydowanie zalecamy używanie tego nagłówka do korelowania działań po stronie klienta z żądaniami odbieranymi przez serwer. Aby uzyskać więcej informacji, zobacz Monitorowanie Azure Blob Storage.

Ta operacja obsługuje również używanie nagłówków warunkowych do wykonywania operacji tylko wtedy, gdy zostanie spełniony określony warunek. Aby uzyskać więcej informacji, zobacz Określanie nagłówków warunkowych dla operacji usługi Blob Service.

Treść żądania

Aby określić przechowywane zasady dostępu, podaj unikatowy identyfikator i zasady dostępu w treści żądania dla Set Container ACL operacji.

Element SignedIdentifier zawiera unikatowy identyfikator określony w elemecie Id oraz szczegóły zasad dostępu, jak określono w elemecie AccessPolicy . Maksymalna długość unikatowego identyfikatora wynosi 64 znaki.

Pola Start i Expiry muszą być wyrażone jako czas UTC i muszą być zgodne z prawidłowym formatem ISO 8061. Obsługiwane formaty ISO 8061 obejmują następujące elementy:

  • YYYY-MM-DD
  • YYYY-MM-DDThh:mmTZD
  • YYYY-MM-DDThh:mm:ssTZD
  • YYYY-MM-DDThh:mm:ss.fffffffTZD

W przypadku części dat tych formatów YYYY jest reprezentacją czterocyfrową roku, MM jest reprezentacją dwucyfrową miesiąca i DD jest reprezentacją dwucyfrową w ciągu dnia. Dla części hh czasu jest reprezentacją godziny w notacji 24-godzinnej, mm jest reprezentacją dwucyfrową minuty, ss dwucyfrową drugą reprezentacją i fffffff jest reprezentacją siedmiocyfrową milisekundy. Wyznaczanie T godziny oddziela fragmenty daty i godziny ciągu, a projektowania TZD strefy czasowej określa strefę czasową.

<?xml version="1.0" encoding="utf-8"?>  
<SignedIdentifiers>  
  <SignedIdentifier>   
    <Id>unique-64-character-value</Id>  
    <AccessPolicy>  
      <Start>start-time</Start>  
      <Expiry>expiry-time</Expiry>  
      <Permission>abbreviated-permission-list</Permission>  
    </AccessPolicy>  
  </SignedIdentifier>  
</SignedIdentifiers>

Przykładowe żądanie

Request Syntax:  
PUT https://myaccount.blob.core.windows.net/mycontainer?restype=container&comp=acl HTTP/1.1  
  
Request Headers:  
x-ms-version: 2011-08-18  
x-ms-date: Sun, 25 Sep 2011 00:42:49 GMT  
x-ms-blob-public-access: container  
Authorization: SharedKey myaccount:V47F2tYLS29MmHPhiR8FyiCny9zO5De3kVSF0RYQHmo=  
  
Request Body:  
<?xml version="1.0" encoding="utf-8"?>  
<SignedIdentifiers>  
  <SignedIdentifier>   
    <Id>MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=</Id>  
    <AccessPolicy>  
      <Start>2009-09-28T08:49:37.0000000Z</Start>  
      <Expiry>2009-09-29T08:49:37.0000000Z</Expiry>  
      <Permission>rwd</Permission>  
    </AccessPolicy>  
  </SignedIdentifier>  
</SignedIdentifiers>

Reakcja

Odpowiedź zawiera kod stanu HTTP i zestaw nagłówków odpowiedzi.

Kod stanu

Pomyślna operacja zwraca kod stanu 200 (OK).

Aby uzyskać więcej informacji na temat kodów stanu, zobacz Kody stanu i błędów.

Nagłówki odpowiedzi

Odpowiedź na tę operację zawiera następujące nagłówki. Odpowiedź może również zawierać dodatkowe standardowe nagłówki HTTP. Wszystkie standardowe nagłówki są zgodne ze specyfikacją protokołu HTTP/1.1.

Nagłówek odpowiedzi Opis
ETag Element ETag dla kontenera. Jeśli wersja żądania to 2011-08-18 lub nowsza, wartość elementu ETag jest ujęta w cudzysłów.
Last-Modified Zwraca datę i godzinę ostatniej modyfikacji kontenera. Format daty jest zgodny z dokumentem RFC 1123. Aby uzyskać więcej informacji, zobacz Reprezentacja wartości daty/godziny w nagłówkach.

Każda operacja, która modyfikuje kontener lub jego właściwości lub metadane, aktualizuje czas ostatniej modyfikacji, w tym ustawianie uprawnień kontenera. Operacje na obiektach blob nie mają wpływu na czas ostatniej modyfikacji kontenera.
x-ms-request-id Unikatowo identyfikuje wykonane żądanie i może służyć do rozwiązywania problemów z żądaniem. Aby uzyskać więcej informacji, zobacz Rozwiązywanie problemów z operacjami interfejsu API
x-ms-version Wskazuje wersję usługi Blob Service, która została użyta do wykonania żądania. Ten nagłówek jest zwracany w przypadku żądań wysyłanych w wersji 2009-09-19 lub nowszej.
Date Wartość daty/godziny UTC wygenerowana przez usługę, która wskazuje godzinę zainicjowania odpowiedzi.
x-ms-client-request-id Może służyć do rozwiązywania problemów z żądaniami i odpowiadającymi odpowiedziami. Wartość tego nagłówka jest równa wartości x-ms-client-request-id nagłówka, jeśli jest obecna w żądaniu, a wartość zawiera nie więcej niż 1024 widoczne znaki ASCII. x-ms-client-request-id Jeśli nagłówek nie znajduje się w żądaniu, nie będzie on obecny w odpowiedzi.

Przykładowa odpowiedź

Response Status:  
HTTP/1.1 200 OK  
  
Response Headers:  
Transfer-Encoding: chunked  
Date: Sun, 25 Sep 2011 22:42:55 GMT  
ETag: "0x8CB171613397EAB"  
Last-Modified: Sun, 25 Sep 2011 22:42:55 GMT  
x-ms-version: 2011-08-18  
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0

Autoryzacja

Operacja Set Container ACL obsługuje tylko autoryzację klucza współużytkowanego.

Uwagi

Tylko właściciel konta może uzyskać dostęp do zasobów w określonym kontenerze, chyba że właściciel określił, że zasoby kontenera są dostępne dla dostępu publicznego, ustawiając uprawnienia w kontenerze lub wystawił sygnaturę dostępu współdzielonego dla zasobu w kontenerze.

Po ustawieniu uprawnień dla kontenera istniejące uprawnienia zostaną zastąpione. Aby zaktualizować uprawnienia kontenera, wywołaj metodę Pobierz listę kontroli dostępu kontenera , aby pobrać wszystkie zasady dostępu skojarzone z kontenerem. Zmodyfikuj zasady dostępu, które chcesz zmienić, a następnie wywołaj Set Container ACL metodę z pełnym zestawem danych w celu przeprowadzenia aktualizacji.

Włączanie anonimowego dostępu publicznego do danych kontenera

Aby włączyć anonimowy publiczny dostęp do odczytu danych kontenera, wywołaj metodę Set Container ACL z nagłówkiem ustawionym x-ms-blob-public-access na container lub blob. Aby wyłączyć dostęp anonimowy, wywołaj metodę Set Container ACL bez określania nagłówka x-ms-blob-public-access .

W przypadku ustawienia wartości x-ms-blob-public-accessblobklienci mogą anonimowo wywoływać następujące operacje:

W przypadku ustawienia wartości x-ms-blob-public-accesscontainerklienci mogą anonimowo wywoływać następujące operacje:

Ustanawianie zasad dostępu na poziomie kontenera

Przechowywane zasady dostępu mogą określać czas rozpoczęcia, czas wygaśnięcia i uprawnienia do sygnatur dostępu współdzielonego, z którymi jest skojarzony. W zależności od tego, jak chcesz kontrolować dostęp do kontenera lub zasobu obiektu blob, możesz określić wszystkie te parametry w przechowywanych zasadach dostępu i pominąć je z adresu URL sygnatury dostępu współdzielonego. W ten sposób można zmodyfikować zachowanie skojarzonego podpisu w dowolnym momencie lub odwołać go. Możesz też określić jeden lub więcej parametrów zasad dostępu w ramach przechowywanych zasad dostępu, a inne w adresie URL. Na koniec możesz określić wszystkie parametry w adresie URL. W takim przypadku można użyć przechowywanych zasad dostępu, aby odwołać podpis, ale nie zmodyfikować jego zachowania. Aby uzyskać więcej informacji, zobacz Definiowanie przechowywanych zasad dostępu.

Razem sygnatura dostępu współdzielonego i przechowywane zasady dostępu muszą zawierać wszystkie pola wymagane do autoryzowania podpisu. Jeśli brakuje wymaganych pól, żądanie zakończy się niepowodzeniem. Podobnie jeśli pole jest określone zarówno w adresie URL sygnatury dostępu współdzielonego, jak i przechowywanych zasadach dostępu, żądanie kończy się niepowodzeniem z kodem stanu 400 (nieprawidłowe żądanie).

Co najwyżej pięć oddzielnych zasad dostępu można ustawić dla pojedynczego kontenera w dowolnym momencie. Jeśli w treści żądania przekazano więcej niż pięć zasad dostępu, usługa zwraca kod stanu 400 (Nieprawidłowe żądanie).

Sygnaturę dostępu współdzielonego można wydać w kontenerze lub obiekcie blob niezależnie od tego, czy dane kontenera są dostępne dla anonimowego dostępu do odczytu. Sygnatura dostępu współdzielonego zapewnia większą kontrolę nad sposobem, kiedy i którym zasób jest dostępny.

Uwaga

Po ustanowieniu przechowywanych zasad dostępu w kontenerze zastosowanie zasad może potrwać do 30 sekund. W tym interwale, dopóki zasady nie staną się aktywne, sygnatura dostępu współdzielonego skojarzona z zapisanymi zasadami dostępu kończy się niepowodzeniem z kodem stanu 403 (Zabronione).

Rozliczenia

Żądania cen mogą pochodzić od klientów korzystających z interfejsów API usługi Blob Storage bezpośrednio za pośrednictwem interfejsu API REST usługi Blob Storage lub biblioteki klienta usługi Azure Storage. Te żądania naliczają opłaty za transakcję. Typ transakcji wpływa na sposób naliczania opłat za konto. Na przykład transakcje odczytu są naliczane w innej kategorii rozliczeniowej niż transakcje zapisu. W poniższej tabeli przedstawiono kategorię rozliczeń dla Set Container ACL żądań na podstawie typu konta magazynu:

Operacja Typ konta magazynu Kategoria rozliczeń
Ustawianie listy ACL kontenerów Blokowy obiekt blob w warstwie Premium
Standardowa ogólnego przeznaczenia, wersja 2		 Inne operacje
Ustawianie listy ACL kontenerów Standardowa ogólnego przeznaczenia, wersja 1 Operacje zapisu

Aby dowiedzieć się więcej o cenach dla określonej kategorii rozliczeniowej, zobacz Azure Blob Storage Cennik.

Zobacz też

Ograniczanie dostępu do kontenerów i obiektów blob
Delegowanie dostępu za pomocą sygnatury dostępu współdzielonego
Tworzenie i używanie sygnatury dostępu współdzielonego
Definiowanie przechowywanych zasad dostępu
Uzyskiwanie listy ACL kontenerów
Autoryzowanie żądań do usługi Azure Storage
Kody stanu i błędów
Kody błędów usługi Blob Service