Udostępnij za pośrednictwem

Ustawianie listy ACL udziałów

  • Artykuł

Operacja Set Share ACL ustawia przechowywane zasady dostępu do użycia z sygnaturami dostępu współdzielonego. Aby uzyskać więcej informacji na temat ustawiania zasad dostępu, zobacz Udzielanie ograniczonego dostępu do zasobów usługi Azure Storage przy użyciu sygnatur dostępu współdzielonego.

Dostępność protokołu

Włączony protokół udziału plików Dostępne
SMB Tak
NFS Nr

Żądanie

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

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

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 Azure Files.

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 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 Wymagane dla wszystkich autoryzowanych żądań. Określa wersję operacji do użycia dla tego żądania. Ta operacja jest dostępna tylko w wersji 2015-02-21 lub nowszej.

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 analityka magazynu 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.
x-ms-lease-id:<ID> Wymagane, jeśli docelowy udział plików ma aktywną dzierżawę. Dostępne dla wersji 2020-02-10 lub nowszej. Jeśli żądanie nie zawiera identyfikatora dzierżawy lub jest nieprawidłowe, operacja kończy się niepowodzeniem z kodem stanu 412 (Warunek wstępny nie powiodło się).

Jeśli ten nagłówek jest określony, a docelowy udział plików nie ma obecnie aktywnej dzierżawy, operacja kończy się niepowodzeniem z kodem stanu 412 (Warunek wstępny nie powiodło się).

Treść żądania

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

Element SignedIdentifier zawiera unikatowy identyfikator określony 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.fffffffTZD

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 fffffff jest reprezentacją siedmiocyfrową milisekundową. Projektator T godziny oddziela fragmenty daty i godziny ciągu. 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.file.core.windows.net/myshare?restype=share&comp=acl HTTP/1.1  
  
Request Headers:  
x-ms-version: 2015-02-21  
x-ms-date: <date>  
Authorization: SharedKey myaccount:V47F2tYLS29MmHPhiR8FyiCny9zO5De3kVSF0RYQHmo=  
  
Request Body:  
<?xml version="1.0" encoding="utf-8"?>  
<SignedIdentifiers>  
  <SignedIdentifier>   
    <Id>MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=</Id>  
    <AccessPolicy>  
      <Start>2015-07-01T08:49:37.0000000Z</Start>  
      <Expiry>2015-07-02T08:49:37.0000000Z</Expiry>  
      <Permission>rwd</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 200 (OK).

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
ETag Zwraca datę i godzinę ostatniej modyfikacji kontenera. Format daty jest zgodny z RFC 1123. Aby uzyskać więcej informacji, zobacz Reprezentacja wartości daty/godziny w nagłówkach.
Last-Modified Każda operacja modyfikując udział lub jego właściwości lub metadane aktualizuje czas ostatniej modyfikacji, w tym ustawienie uprawnień pliku. Operacje na plikach nie wpływają na czas ostatniej modyfikacji udziału.
x-ms-request-id Jednoznacznie identyfikuje żądanie, które zostało wykonane i może być używane 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ę Azure Files, która została użyta do wykonania żądania.
Date lub x-ms-date Wartość daty/godziny UTC wskazująca godzinę, w 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 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ść wynosi co najwyżej 1024 widoczne znaki ASCII. x-ms-client-request-id Jeśli nagłówek nie znajduje się w żądaniu, ten nagłówek nie będzie obecny w odpowiedzi.

Przykładowa odpowiedź

Response Status:  
HTTP/1.1 200 OK  
  
Response Headers:  
Transfer-Encoding: chunked  
Date: <date>  
ETag: "0x8CB171613397EAB"  
Last-Modified: <date>  
x-ms-version: 2015-02-21  
Server: Windows-Azure-File/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ślonym udziale, chyba że spełniony jest jeden z następujących warunków:

  • Właściciel określił, że zasoby udziału są dostępne dla dostępu publicznego, ustawiając uprawnienia do udziału.
  • Właściciel wydał sygnaturę dostępu współdzielonego dla zasobu w udziale.

Po ustawieniu uprawnień dla kontenera istniejące uprawnienia zostaną zastąpione. Aby zaktualizować uprawnienia kontenera, wywołaj metodę Pobierz listę ACL udziału , aby pobrać wszystkie zasady dostępu skojarzone z kontenerem. Zmodyfikuj zasady dostępu, które chcesz zmienić, a następnie wywołaj Set Share ACL pełny zestaw danych, aby przeprowadzić aktualizację.

Ustanawianie zasad dostępu na poziomie udziału

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 udziału lub zasobu plików, możesz:

  • Określ wszystkie te parametry w przechowywanych zasadach dostępu i pomiń je z adresu URL dla sygnatury dostępu współdzielonego. Dzięki temu można zmodyfikować zachowanie skojarzonego podpisu lub odwołać je w dowolnym momencie.
  • Określ co najmniej jeden parametr 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 ustawiania zasad dostępu, zobacz Udzielanie ograniczonego dostępu do zasobów usługi Azure Storage przy użyciu sygnatur dostępu współdzielonego.

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 Używanie sygnatury dostępu współdzielonego.

W dowolnym momencie można ustawić maksymalnie pięć oddzielnych zasad dostępu dla udziału. 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).

Sygnatura dostępu współdzielonego może zostać wystawiona w udziale lub pliku niezależnie od tego, czy dane kontenera są dostępne do anonimowego dostępu do odczytu. Sygnatura dostępu współdzielonego zapewnia większą kontrolę nad tym, jak, kiedy i do kogo jest udostępniany zasób.

Nie można ustawić ani pobrać zasad dostępu dla migawki udziału. Jeśli spróbujesz ustawić zasady dostępu, usługa zwróci kod stanu 400 (InvalidQueryParameterValue).

Uwaga

Po ustanowieniu przechowywanych zasad dostępu w kontenerze 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ż

Operacje na zasobach udziałów plików (Azure Files)