Udostępnij za pośrednictwem

Ustawianie listy ACL tabel

  • Artykuł

Operacja Set Table ACL ustawia przechowywane zasady dostępu dla tabeli, które mogą być używane z sygnaturami dostępu współdzielonego. Aby uzyskać więcej informacji, zobacz Definiowanie przechowywanych zasad dostępu.

Nuta

Operacja Set Table ACL jest dostępna w wersji 2012-02-12 lub nowszej.

Nuta

Lista listy kontroli dostępu (ACL) to lista wpisów kontroli dostępu (ACL). Każda usługa ACE w liście ACL identyfikuje zaufania i określa prawa dostępu dozwolone, odrzucone lub poddane inspekcji dla tego zaufania. Aby uzyskać więcej informacji, zobacz listy kontroli dostępu.

Prosić

Żądanie Set Table ACL można skonstruować w następujący sposób. Zalecamy użycie protokołu HTTPS. Zastąp wartość myaccount nazwą konta magazynu.

Metoda Identyfikator URI żądania Wersja PROTOKOŁU HTTP
PUT https://myaccount.table.core.windows.net/mytable?comp=acl HTTP/1.1

Identyfikator URI usługi magazynu emulowanego

Gdy wysyłasz żądanie względem emulowanej usługi magazynu, określ nazwę hosta emulatora i port usługi Azure Table Storage jako 127.0.0.1:10002. Następnie dodaj emulowaną nazwę konta magazynu.

Metoda Identyfikator URI żądania Wersja PROTOKOŁU HTTP
PUT http://127.0.0.1:10002/devstoreaccount1/mytable?comp=acl HTTP/1.1

Aby uzyskać więcej informacji, zobacz Use the Azurite emulator for local Azure Storage development.

Parametry identyfikatora URI

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

Parametr Opis
timeout Fakultatywny. Wyrażone w sekundach. Aby uzyskać więcej informacji, zobacz Ustawianie limitów czasu dla operacji usługi Table Storage.

Nagłówki żądań

W poniższej tabeli opisano wymagane i opcjonalne nagłówki żądań:

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 uniwersalny czas koordynowany (UTC) dla żądania. Aby uzyskać więcej informacji, zobacz Autoryzowanie żądań do usługi Azure Storage.
x-ms-version Fakultatywny. 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-client-request-id Fakultatywny. Zapewnia nieprzezroczystą wartość wygenerowaną przez klienta z limitem znaków 1-kibibyte (KiB), który jest rejestrowany w dziennikach analizy magazynu podczas konfigurowania rejestrowania. Zdecydowanie zalecamy używanie tego nagłówka do korelowania działań po stronie klienta z żądaniami odbieranymi przez serwer.

Treść żądania

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

Element SignedIdentifier zawiera unikatowy identyfikator, jak określono w elemecie Id. SignedIdentifier zawiera również 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ą:

  • YYYY-MM-DD

  • YYYY-MM-DDThh:mmTZD

  • YYYY-MM-DDThh:mm:ssTZD

  • YYYY-MM-DDThh:mm:ss.ffffffTZD

W przypadku części dat tych formatów YYYY jest czterocyfrową reprezentacją roku, MM jest dwucyfrową reprezentacją miesiąca, a DD jest dwucyfrową reprezentacją dnia. W przypadku części czasu hh jest reprezentacją godziny w notacji 24-godzinnej, mm jest dwucyfrową reprezentacją minut, ss jest dwucyfrową drugą reprezentacją, a ffffff jest reprezentacją sześciocyfrową milisekundową. Projektant czasu T oddziela część daty i godziny ciągu. Projektant strefy czasowej TZD 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.table.core.windows.net/mytable?comp=acl HTTP/1.1  
  
Request Headers:  
x-ms-version: 2013-08-15  
x-ms-date: Mon, 25 Nov 2013 00:42:49 GMT  
Authorization: SharedKey myaccount:V47F2tYLS29MmHPhiR8FyiCny9zO5De3kVSF0RYQHmo=  
  
Request Body:  
<?xml version="1.0" encoding="utf-8"?>  
<SignedIdentifiers>  
  <SignedIdentifier>   
    <Id>MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=</Id>  
    <AccessPolicy>  
      <Start>2013-11-26T08:49:37.0000000Z</Start>  
      <Expiry>2013-11-27T08:49:37.0000000Z</Expiry>  
      <Permission>raud</Permission>  
    </AccessPolicy>  
  </SignedIdentifier>  
</SignedIdentifiers>

Odpowiedź

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

Kod stanu

Pomyślna operacja zwraca kod stanu 204 (Brak zawartości).

Aby uzyskać informacje o kodach stanu, zobacz Stan i kody błędów.

Nagłówki odpowiedzi

Odpowiedź dla tej operacji 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
x-ms-request-id Jednoznacznie identyfikuje żądanie, które zostało wykonane. Można go również 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 Table Storage używaną do wykonania żądania. Ten nagłówek jest zwracany dla żądań wysyłanych w wersji 2009-09-19 lub nowszej.
Date Wartość daty/godziny UTC wskazująca godzinę, o której usługa wysłała odpowiedź.
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 nagłówka x-ms-client-request-id, jeśli jest obecna w żądaniu, a wartość wynosi najwyżej 1024 widoczne znaki ASCII. Jeśli nagłówek x-ms-client-request-id nie znajduje się w żądaniu, ten nagłówek nie będzie obecny w odpowiedzi.

Przykładowa odpowiedź

Response Status:  
HTTP/1.1 204 No Content  
  
Response Headers:  
Transfer-Encoding: chunked  
Date: Mon, 25 Nov 2013 22:42:55 GMT  
x-ms-version: 2013-08-15  
Server: Windows-Azure-Table/1.0 Microsoft-HTTPAPI/2.0

Autoryzacja

Autoryzacja jest wymagana podczas wywoływania dowolnej operacji dostępu do danych w usłudze Azure Storage. Operację Set Table ACL można autoryzować przy użyciu identyfikatora entra firmy Microsoft lub klucza współużytkowanego.

Aby autoryzować operację Set Table ACL przy użyciu identyfikatora Entra firmy Microsoft, podmiot zabezpieczeń potrzebuje niestandardowej roli RBAC platformy Azure, która obejmuje następującą akcję RBAC: Microsoft.Storage/storageAccounts/tableServices/tables/setAcl/action.

Ważny

Firma Microsoft zaleca używanie identyfikatora Entra firmy Microsoft z tożsamościami zarządzanymi w celu autoryzowania żądań do usługi Azure Storage. Identyfikator Entra firmy Microsoft zapewnia lepsze zabezpieczenia i łatwość użycia w porównaniu z autoryzacją klucza współdzielonego.

Uwagi

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

Ustanawianie przechowywanych zasad dostępu

Przechowywane zasady dostępu mogą określać czas rozpoczęcia, czas wygaśnięcia i uprawnienia dla sygnatur dostępu współdzielonego, z którymi jest skojarzony. W zależności od tego, jak chcesz kontrolować dostęp do udziału lub zasobu plików, możesz:

  • Określ wszystkie te parametry w przechowywanych zasadach dostępu i pomiń je z adresu URL sygnatury dostępu współdzielonego. Umożliwia to modyfikowanie zachowania skojarzonego podpisu lub odwoływanie go w dowolnym momencie.
  • Określ co najmniej jeden z parametrów zasad dostępu w przechowywanych zasadach dostępu i określ inne parametry w adresie URL.
  • Określ 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 na temat ustanawiania zasad dostępu, 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 żadnych 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 w przechowywanych zasadach dostępu, żądanie zakończy się niepowodzeniem z kodem stanu 400 (nieprawidłowe żądanie). Aby uzyskać więcej informacji na temat pól tworzących sygnaturę dostępu współdzielonego, zobacz Tworzenie sygnatury dostępu współdzielonego usługi.

W dowolnym momencie można ustawić maksymalnie pięć oddzielnych zasad dostępu dla tabeli. Jeśli w treści żądania przekazano więcej niż pięć zasad dostępu, usługa zwraca kod stanu 400 (nieprawidłowe żądanie).

Nuta

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

Zobacz też

Definiowanie przechowywanych zasad dostępu
Tworzenie i używanie sygnatury dostępu współdzielonego
Delegowanie dostępu za pomocą sygnatury dostępu współdzielonego
pobieranie listy ACL tabel
autoryzowanie żądań do usługi Azure Storage
kody stanu i błędów