Impostare l'ACL del contenitore

L'operazione Set Container ACL imposta le autorizzazioni per il contenitore specificato. Le autorizzazioni indicano se è possibile accedere pubblicamente ai BLOB in un contenitore.

A partire dalla versione 2009-09-19, le autorizzazioni del contenitore forniscono le opzioni seguenti per la gestione dell'accesso al contenitore:

• Accesso in lettura pubblico completo: i dati contenitore e BLOB possono essere letti tramite richiesta anonima. I client possono enumerare i BLOB all'interno del contenitore tramite una richiesta anonima, ma non possono enumerare i contenitori all'interno dell'account di archiviazione.

• accesso in lettura pubblico solo per i BLOB: i dati BLOB all'interno di questo contenitore possono essere letti tramite richiesta anonima, ma i dati del contenitore non sono disponibili. I client non possono enumerare i BLOB all'interno del contenitore tramite una richiesta anonima.

• Nessun accesso in lettura pubblico: i dati contenitore e BLOB possono essere letti solo dal proprietario dell'account.

Set Container ACL imposta anche un criterio di accesso archiviato da usare con firme di accesso condiviso. Per altre informazioni, vedere Definire un criterio di accesso archiviato.

Tutto l'accesso pubblico al contenitore è anonimo, così come è l'accesso tramite una firma di accesso condiviso.

Richiesta

La richiesta di Set Container ACL può essere costruita nel modo seguente. È consigliabile usare HTTPS. Sostituire myaccount con il nome dell'account di archiviazione:

Richiesta del servizio di archiviazione emulata

Quando si effettua una richiesta per il servizio di archiviazione emulato, specificare il nome host dell'emulatore e la porta del servizio BLOB come 127.0.0.1:10000, seguito dal nome dell'account di archiviazione emulato:

Per altre informazioni, vedere Usare l'emulatore Azurite per lo sviluppo locale di Archiviazione di Azure.

Parametri URI

È possibile specificare i parametri aggiuntivi seguenti nell'URI della richiesta:

Intestazioni della richiesta

Le intestazioni di richiesta obbligatorie e facoltative sono descritte nella tabella seguente:

Questa operazione supporta anche l'uso di intestazioni condizionali per eseguire l'operazione solo se viene soddisfatta una condizione specificata. Per altre informazioni, vedere Specificare le intestazioni condizionali per le operazioni del servizio BLOB.

Corpo della richiesta

Per specificare un criterio di accesso archiviato, specificare un identificatore univoco e un criterio di accesso nel corpo della richiesta per l'operazione di Set Container ACL.

L'elemento SignedIdentifier include l'identificatore univoco, come specificato nell'elemento Id e i dettagli dei criteri di accesso, come specificato nell'elemento AccessPolicy. La lunghezza massima dell'identificatore univoco è di 64 caratteri.

I campi Start e Expiry devono essere espressi come ore UTC e devono essere conformi a un formato ISO 8061 valido. I formati ISO 8061 supportati includono quanto segue:

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

Per la parte data di questi formati, YYYY è una rappresentazione dell'anno a quattro cifre, MM è una rappresentazione mensile a due cifre e DD è una rappresentazione di giorno a due cifre. Per la parte temporale, hh è la rappresentazione dell'ora nella notazione di 24 ore, mm è la rappresentazione di minuti a due cifre, ss è la rappresentazione in seconda cifra e fffffff è la rappresentazione in millisecondi a sette cifre. Un designatore dell'ora T separa le parti di data e ora della stringa e un designatore del fuso orario TZD specifica un fuso orario.

<?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>  
  

Richiesta di esempio

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>  
  

Risposta

La risposta include un codice di stato HTTP e un set di intestazioni di risposta.

Codice di stato

Un'operazione riuscita restituisce il codice di stato 200 (OK).

Per altre informazioni sui codici di stato, vedere Stato e codici di errore.

Intestazioni di risposta

La risposta per questa operazione include le intestazioni seguenti. La risposta può includere anche intestazioni HTTP standard aggiuntive. Tutte le intestazioni standard sono conformi alla specifica del protocollo HTTP/1.1 .

Risposta di esempio

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  

Autorizzazione

L'autorizzazione è necessaria quando si chiama un'operazione di accesso ai dati in Archiviazione di Azure. È possibile autorizzare l'operazione di Set Container ACL come descritto di seguito.

Osservazioni

Quando si impostano le autorizzazioni per un contenitore, le autorizzazioni esistenti vengono sostituite. Per aggiornare le autorizzazioni del contenitore, chiamare Get Container ACL per recuperare tutti i criteri di accesso associati al contenitore. Modificare i criteri di accesso da modificare e quindi chiamare Set Container ACL con il set completo di dati per eseguire l'aggiornamento.

Abilitare l'accesso pubblico anonimo nei dei dati del contenitore

Per abilitare l'accesso in lettura pubblico anonimo sui dati del contenitore, chiamare Set Container ACL con l'intestazione x-ms-blob-public-access impostata su container o blob. Per disabilitare l'accesso anonimo, chiamare Set Container ACL senza specificare l'intestazione x-ms-blob-public-access.

Se si imposta x-ms-blob-public-access su blob, i client possono chiamare le operazioni seguenti in modo anonimo:

• Ottenere BLOB

• ottenere le proprietà del BLOB

• ottenere i metadati blob

• get block list (solo per l'elenco di blocchi di cui è stato eseguito il commit)

• Ottenere intervalli di pagine

Se si imposta x-ms-blob-public-access su container, i client possono chiamare le operazioni seguenti in modo anonimo:

• Le operazioni di accesso ai BLOB elencate nella sezione precedente.

• Ottenere le proprietà del contenitore

• ottenere i metadati del contenitore

• list BLOB

Stabilire criteri di accesso a livello di contenitore

I criteri di accesso archiviati possono specificare l'ora di inizio, l'ora di scadenza e le autorizzazioni per le firme di accesso condiviso a cui è associata. A seconda di come si vuole controllare l'accesso al contenitore o alla risorsa BLOB, è possibile specificare tutti questi parametri all'interno dei criteri di accesso archiviati e ometterli dall'URL per la firma di accesso condiviso. In questo modo, è possibile modificare il comportamento della firma associata in qualsiasi momento o revocarlo. In alternativa, è possibile specificare uno o più parametri dei criteri di accesso all'interno dei criteri di accesso archiviati e gli altri nell'URL. Infine, è possibile specificare tutti i parametri nell'URL. In questo caso, è possibile usare i criteri di accesso archiviati per revocare la firma, ma non per modificarne il comportamento. Per altre informazioni, vedere Definire un criterio di accesso archiviato.

Insieme, la firma di accesso condiviso e i criteri di accesso archiviati devono includere tutti i campi necessari per autorizzare la firma. Se mancano campi obbligatori, la richiesta ha esito negativo. Analogamente, se un campo viene specificato sia nell'URL della firma di accesso condiviso che nei criteri di accesso archiviati, la richiesta ha esito negativo con codice di stato 400 (richiesta non valida).

Al massimo, è possibile impostare cinque criteri di accesso separati per un singolo contenitore in qualsiasi momento. Se nel corpo della richiesta vengono passati più di cinque criteri di accesso, il servizio restituisce il codice di stato 400 (richiesta non valida).

È possibile emettere una firma di accesso condiviso in un contenitore o in un BLOB indipendentemente dal fatto che i dati del contenitore siano disponibili per l'accesso in lettura anonimo. Una firma di accesso condiviso offre una maggiore misura del controllo su come, quando e a chi una risorsa viene resa accessibile.

Fatturazione

Le richieste di prezzi possono provenire dai client che usano le API di archiviazione BLOB, direttamente tramite l'API REST dell'archiviazione BLOB o da una libreria client di Archiviazione di Azure. Queste richieste accumulano addebiti per transazione. Il tipo di transazione influisce sulla modalità di addebito dell'account. Ad esempio, le transazioni di lettura si accumulano in una categoria di fatturazione diversa rispetto alle transazioni di scrittura. La tabella seguente illustra la categoria di fatturazione per Set Container ACL richieste in base al tipo di account di archiviazione:

Per informazioni sui prezzi per la categoria di fatturazione specificata, vedere prezzi di Archiviazione BLOB di Azure.

Vedere anche

Limitare l'accesso a contenitori e BLOB
Delegare l'accesso con una firma di accesso condiviso
Creare e usare una firma di accesso condiviso
Definire un criterio di accesso archiviato
Get Container ACL
Autorizzare le richieste ad Archiviazione di Azure
codici di errore e stato
codici di errore del servizio BLOB