Ustawianie listy ACL kolejki

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.

Uwaga

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

Żądanie

Żądanie można skonstruować Set Queue ACL w następujący sposób. Zalecamy używanie protokołu HTTPS. Zastąp ciąg 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

Żądanie usługi magazynu emulowanego

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 (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 kolejki.

Nagłówki żądań

Wymagane i opcjonalne nagłówki żądań opisano 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 usług Azure Storage.
x-ms-client-request-id	Opcjonalny. Udostępnia 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 Monitorowanie usługi Azure Queue Storage.

Treść żądania

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

Element SignedIdentifier zawiera unikatowy identyfikator, określony w Id elemecie, 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 i DD jest dwucyfrową reprezentacją dnia. W przypadku części hh czasowej jest reprezentacją godziny w notacji 24-godzinnej, mm jest dwucyfrową reprezentacją minuty, ss jest dwucyfrową drugą reprezentacją i ffffff jest sześciocyfrową reprezentacją milisekundową. Projektator T godziny oddziela fragmenty daty i godziny ciągu, a projektator 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.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>  
  

Reakcja

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

Kod stanu

Operacja zakończona powodzeniem zwraca kod stanu 204 (Brak zawartości).

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 nagłówki standardowe są zgodne ze specyfikacją protokołu HTTP/1.1.

Nagłówek odpowiedzi	Opis
x-ms-request-id	Jednoznacznie 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 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 im odpowiedziami. Wartość tego nagłówka jest równa wartości x-ms-client-request-id nagłówka, jeśli znajduje się w żądaniu, a wartość nie zawiera więcej niż 1024 widocznych znaków ASCII. x-ms-client-request-id Jeśli nagłówek nie jest obecny 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

Tylko właściciel konta może wywołać tę operację.

Uwagi

Tylko właściciel konta może uzyskać dostęp do zasobów w określonej kolejce, chyba że właściciel wystawił sygnaturę dostępu współdzielonego zasobu w kolejce.

Po ustawieniu uprawnień dla kolejki istniejące uprawnienia zostaną zastąpione. Aby zaktualizować uprawnienia kolejki, wywołaj metodę 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 pełny zestaw danych, aby przeprowadzić aktualizację.

Ustanawianie przechowywanych zasad dostępu

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 zasobu kolejki, można 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ć co najmniej jeden parametr zasad dostępu w przechowywanych zasadach dostępu, a inne w adresie URL. Na koniec można 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 zostanie przekazanych więcej niż pięć zasad dostępu, usługa zwróci 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 zapisanymi 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