Ustawianie listy ACL kolejek

Operacja Set Queue ACL ustawia przechowywane zasady dostępu dla kolejki, które mogą być używane z sygnaturą dostępu współdzielonego (sygnatura dostępu współdzielonego). Aby uzyskać więcej informacji, zobacz Definiowanie przechowywanych zasad dostępu.

Nuta

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

Prosić

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

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

Emulowane żądanie usługi magazynu

Gdy wysyłasz żądanie względem emulowanej usługi magazynu, określ nazwę hosta emulatora i port usługi kolejki jako 127.0.0.1:10001, a następnie nazwę emulowanego konta magazynu:

Metoda	Identyfikator URI żądania	Wersja PROTOKOŁU HTTP
PUT	http://127.0.0.1:10001/devstoreaccount1/myqueue?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. Parametr timeout jest wyrażony w sekundach. Aby uzyskać więcej informacji, zobacz Ustawianie limitów czasu dla operacji usługi kolejkowania.

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 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 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 Monitor Azure Queue Storage.

Treść żądania

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

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.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ęści daty i godziny ciągu, a 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.queue.core.windows.net/myqueue?comp=acl HTTP/1.1  
  
Request Headers:  
x-ms-version: 2012-02-12  
x-ms-date: Sun, 25 Sep 2011 00:42:49 GMT  
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>raup</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ć więcej informacji na temat kodów 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 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 Kolejki, która została użyta do wykonania żądania. Ten nagłówek jest zwracany dla żądań, które zostały wykonane 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	Ten nagłówek 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 znajduje się w żądaniu, a wartość nie zawiera więcej niż 1024 widocznych znaków ASCII. Jeśli nagłówek x-ms-client-request-id nie znajduje się w żądaniu, nie będzie on obecny w odpowiedzi.

Przykładowa odpowiedź

Response Status:  
HTTP/1.1 204 No Content  
  
Response Headers:  
Transfer-Encoding: chunked  
Date: Sun, 25 Sep 2011 22:42:55 GMT  
x-ms-version: 2012-02-12  
Server: Windows-Azure-Queue/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 Queue ACL można autoryzować przy użyciu identyfikatora entra firmy Microsoft lub klucza współużytkowanego.

Aby autoryzować operację Set Queue 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/queueServices/queues/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 kolejki istniejące uprawnienia zostaną zastąpione. Aby zaktualizować uprawnienia kolejki, wywołaj Pobierz listę ACL kolejki, aby pobrać wszystkie zasady dostępu skojarzone z kolejką. Zmodyfikuj zasady dostępu, które chcesz zmienić, a następnie wywołaj Set Queue 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 zasobu kolejki, możesz określić wszystkie te parametry w przechowywanych zasadach dostępu i pominąć je z adresu URL sygnatury dostępu współdzielonego. Dzięki temu można zmodyfikować zachowanie skojarzonego podpisu w dowolnym momencie lub odwołać je. Możesz też określić jeden lub więcej parametrów zasad dostępu w przechowywanych zasadach dostępu, a inne na 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 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 jakichkolwiek 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 kończy się niepowodzeniem z kodem stanu 400 (nieprawidłowe żądanie).

Co najwyżej pięć oddzielnych zasad dostępu można ustawić dla jednej kolejki 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).

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

Zobacz też

Definiowanie przechowywanych zasad dostępu
uzyskiwanie listy ACL kolejek
autoryzowanie żądań do usługi Azure Storage
kody stanu i błędów