Set Queue ACL

Articolo
06/27/2023

L'operazione Set Queue ACL imposta i criteri di accesso archiviati per la coda che possono essere usati con una firma di accesso condiviso (firma di accesso condiviso). Per altre informazioni, vedere Definire un criterio di accesso archiviato.

Nota

L'operazione Set Queue ACL è disponibile nella versione 2012-02-12 e successive.

Richiesta

È possibile costruire la Set Queue ACL richiesta come indicato di seguito. È consigliabile usare HTTPS. Sostituire myaccount con il nome dell'account di archiviazione:

Metodo	URI richiesta	Versione HTTP
`PUT`	`https://myaccount.queue.core.windows.net/myqueue?comp=acl`	HTTP/1.1

Richiesta di servizio di archiviazione emulata

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

Metodo	URI richiesta	Versione HTTP
`PUT`	`http://127.0.0.1:10001/devstoreaccount1/myqueue?comp=acl`	HTTP/1.1

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

Parametri URI

Nell'URI della richiesta puoi specificare i parametri seguenti:

Parametro	Descrizione
`timeout`	Facoltativa. Il parametro `timeout` viene espresso in secondi. Per altre informazioni, vedere Impostare i timeout per le operazioni del servizio di accodamento.

Intestazioni della richiesta

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

Intestazione della richiesta	Descrizione
`Authorization`	Obbligatorio. Specifica lo schema di autorizzazione, il nome dell'account e la firma. Per altre informazioni, vedere Autorizzare le richieste ad Archiviazione di Azure.
`Date` o `x-ms-date`	Obbligatorio. Specifica la data per la richiesta nel fuso orario UTC (Coordinated Universal Time). Per altre informazioni, vedere Autorizzare le richieste ad Archiviazione di Azure.
`x-ms-version`	Facoltativa. Specifica la versione dell'operazione da usare per questa richiesta. Per altre informazioni, vedere Controllo delle versioni per i servizi di archiviazione di Azure.
`x-ms-client-request-id`	Facoltativa. Fornisce un valore opaco generato dal client con un limite di caratteri di 1 kibibyte (KiB) registrato nei log al momento della configurazione della registrazione. È consigliabile usare questa intestazione per correlare le attività lato client alle richieste ricevute dal server. Per altre informazioni, vedere Monitorare l'archiviazione code di Azure.

Testo della richiesta

Per specificare criteri di accesso archiviati, specificare un identificatore univoco e criteri di accesso nel corpo della richiesta per l'operazione Set Queue ACL.

L'elemento SignedIdentifier contiene 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 è 64 caratteri.

I campi Start e Expiry devono essere espressi come ore UTC ed essere conformi a un formato ISO 8061 valido. Di seguito sono elencati alcuni formati ISO 8061 supportati:

YYYY-MM-DD
YYYY-MM-DDThh:mmTZD
YYYY-MM-DDThh:mm:ssTZD
YYYY-MM-DDThh:mm:ss.ffffffTZD

Per la parte relativa alla data di questi formati, YYYY è una rappresentazione dell'anno a quattro cifre, MM è la rappresentazione del mese a due cifre e DD è la rappresentazione del giorno a due cifre. Per la parte relativa all'ora, hh è la rappresentazione dell'ora nel formato 24 ore, mm è la rappresentazione dei minuti a due cifre, ss è la rappresentazione dei secondi a due cifre e ffffff è la rappresentazione dei millisecondi a sei cifre. Un designatore T di ora separa le parti di data e ora della stringa e un designatore TZD di fuso orario 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.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>

Risposta

Nella risposta sono inclusi un codice di stato HTTP e un set di intestazioni per la risposta.

Codice stato

Un'operazione completata correttamente restituisce il codice di stato 204 (Nessun contenuto).

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

Intestazioni di risposta

Nella risposta per questa operazione sono incluse le intestazioni riportate di seguito; inoltre, possono essere incluse intestazioni HTTP standard aggiuntive. Tutte le intestazioni standard sono conformi alla specifica del protocollo HTTP/1.1.

Intestazione risposta	Descrizione
`x-ms-request-id`	Identifica in modo univoco la richiesta effettuata e può essere usata per risolvere i problemi della richiesta. Per altre informazioni, vedere Risolvere i problemi relativi alle operazioni api.
`x-ms-version`	Indica la versione del servizio di accodamento utilizzata per eseguire la richiesta. Questa intestazione viene restituita per le richieste effettuate rispetto alla versione 2009-09-19 e successive.
`Date`	Valore di data/ora UTC generato dal servizio, che indica l'ora di avvio della risposta.
`x-ms-client-request-id`	Questa intestazione può essere usata per risolvere i problemi relativi alle richieste e alle risposte corrispondenti. Il valore di questa intestazione è uguale al valore dell'intestazione `x-ms-client-request-id` se è presente nella richiesta e il valore non contiene più di 1.024 caratteri ASCII visibili. Se l'intestazione `x-ms-client-request-id` non è presente nella richiesta, non sarà presente nella risposta.

Risposta di esempio

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

Autorizzazione

Solo il proprietario dell'account può chiamare questa operazione.

Commenti

Solo il proprietario dell'account può accedere alle risorse in una determinata coda, a meno che il proprietario non abbia emesso una firma di accesso condiviso per una risorsa all'interno della coda.

Quando si impostano le autorizzazioni per una coda, le autorizzazioni esistenti vengono sostituite. Per aggiornare le autorizzazioni della coda, chiamare Get Queue ACL per recuperare tutti i criteri di accesso associati alla coda. Modificare i criteri di accesso da modificare e quindi chiamare Set Queue ACL con il set completo di dati per eseguire l'aggiornamento.

Stabilire criteri di accesso archiviati

Un criterio di accesso archiviato può 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 alla risorsa della coda, è 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 sulla definizione dei criteri di accesso, 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 una singola coda 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).

Quando si stabilisce un criterio di accesso archiviato in una coda, l'applicazione potrebbe richiedere fino a 30 secondi. Durante questo intervallo, una firma di accesso condiviso associata ai criteri di accesso archiviati ha esito negativo con il codice di stato 403 (Accesso negato), fino a quando i criteri di accesso non diventano attivi.

Vedi anche

Definire criteri di accesso archiviati
Get Queue ACL
Autorizzare le richieste ad Archiviazione di Azure
Stato e codici errore