Definir ACL de Fila
A Set Queue ACL
operação define as políticas de acesso armazenadas para a fila que podem ser utilizadas com uma SAS (assinatura de acesso partilhado). Para obter mais informações, veja Definir uma política de acesso armazenado.
Nota
A Set Queue ACL
operação está disponível na versão 2012-02-12 e posterior.
Pedir
Pode construir o pedido da Set Queue ACL
seguinte forma. Recomendamos que utilize HTTPS.
Substitua myaccount pelo nome da sua conta de armazenamento:
Método | URI do pedido | Versão HTTP |
---|---|---|
PUT |
https://myaccount.queue.core.windows.net/myqueue?comp=acl |
HTTP/1.1 |
Pedido de serviço de armazenamento emulado
Quando estiver a fazer um pedido contra o serviço de armazenamento emulado, especifique o nome do anfitrião do emulador e a porta do serviço Fila como 127.0.0.1:10001
, seguido do nome da conta de armazenamento emulada:
Método | URI do pedido | Versão HTTP |
---|---|---|
PUT |
http://127.0.0.1:10001/devstoreaccount1/myqueue?comp=acl |
HTTP/1.1 |
Para obter mais informações, veja Utilizar o emulador do Azurite para o desenvolvimento local do Armazenamento do Azure.
Parâmetros URI
Pode especificar os seguintes parâmetros adicionais no URI do pedido:
Parâmetro | Description |
---|---|
timeout |
Opcional. O timeout parâmetro é expresso em segundos. Para obter mais informações, veja Definir tempos limite para operações do serviço Fila. |
Cabeçalhos do pedido
Os cabeçalhos de pedido obrigatórios e opcionais estão descritos na seguinte tabela:
Cabeçalho do pedido | Description |
---|---|
Authorization |
Obrigatório. Especifica o esquema de autorização, o nome da conta e a assinatura. Para obter mais informações, veja Autorizar pedidos para o Armazenamento do Azure. |
Date ou x-ms-date |
Obrigatório. Especifica a Hora Universal Coordenada (UTC) do pedido. Para obter mais informações, veja Autorizar pedidos para o Armazenamento do Azure. |
x-ms-version |
Opcional. Especifica a versão da operação a utilizar para este pedido. Para obter mais informações, veja Controlo de versões dos serviços de Armazenamento do Azure. |
x-ms-client-request-id |
Opcional. Fornece um valor opaco gerado pelo cliente com um limite de carateres de 1 kibibyte (KiB) que é registado nos registos quando o registo é configurado. Recomendamos vivamente que utilize este cabeçalho para correlacionar as atividades do lado do cliente com os pedidos que o servidor recebe. Para obter mais informações, veja Monitorizar o Armazenamento de Filas do Azure. |
Corpo do pedido
Para especificar uma política de acesso armazenada, forneça um identificador exclusivo e uma política de acesso no corpo do pedido para a Set Queue ACL
operação.
O SignedIdentifier
elemento inclui o identificador exclusivo, conforme especificado no Id
elemento, e os detalhes da política de acesso, conforme especificado no AccessPolicy
elemento. O comprimento máximo do identificador exclusivo é de 64 carateres.
Os Start
campos e Expiry
têm de ser expressos como horas UTC e têm de cumprir um formato ISO 8061 válido. Os formatos ISO 8061 suportados incluem o seguinte:
YYYY-MM-DD
YYYY-MM-DDThh:mmTZD
YYYY-MM-DDThh:mm:ssTZD
YYYY-MM-DDThh:mm:ss.ffffffTZD
Para a parte de data destes formatos, YYYY
é uma representação de quatro dígitos, MM
é uma representação de dois dígitos por mês e DD
é uma representação diária de dois dígitos. Para a parte do tempo, hh
é a representação de hora na notação de 24 horas, mm
é a representação ss
de dois dígitos, é a segunda representação de dois dígitos e ffffff
é a representação de milissegundos de seis dígitos. Um designador T
de hora separa as partes de data e hora da cadeia e um designador TZD
de fuso horário especifica um fuso horário.
<?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>
Pedido de exemplo
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>
Resposta
A resposta inclui um código de estado HTTP e um conjunto de cabeçalhos de resposta.
Código de estado
Uma operação bem-sucedida devolve o código de estado 204 (Sem Conteúdo).
Para obter mais informações sobre códigos de estado, veja Códigos de estado e de erro.
Cabeçalhos de resposta
A resposta para esta operação inclui os seguintes cabeçalhos. A resposta também pode incluir cabeçalhos HTTP padrão adicionais. Todos os cabeçalhos padrão estão em conformidade com a especificação do protocolo HTTP/1.1.
Cabeçalho de resposta | Descrição |
---|---|
x-ms-request-id |
Identifica exclusivamente o pedido que foi feito e pode ser utilizado para resolver o pedido. Para obter mais informações, veja Resolver problemas de operações da API. |
x-ms-version |
Indica a versão do serviço Fila que foi utilizada para executar o pedido. Este cabeçalho é devolvido para pedidos efetuados na versão 2009-09-19 e posterior. |
Date |
Um valor de data/hora UTC gerado pelo serviço, que indica a hora em que a resposta foi iniciada. |
x-ms-client-request-id |
Este cabeçalho pode ser utilizado para resolver problemas de pedidos e respostas correspondentes. O valor deste cabeçalho é igual ao valor do x-ms-client-request-id cabeçalho se estiver presente no pedido e o valor não contiver mais de 1024 carateres ASCII visíveis. Se o x-ms-client-request-id cabeçalho não estiver presente no pedido, não estará presente na resposta. |
Resposta de amostra
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
Autorização
Apenas o proprietário da conta pode chamar esta operação.
Observações
Apenas o proprietário da conta pode aceder a recursos numa fila específica, a menos que o proprietário tenha emitido uma assinatura de acesso partilhado para um recurso na fila.
Quando define permissões para uma fila, as permissões existentes são substituídas. Para atualizar as permissões da fila, chame Obter ACL de Fila para obter todas as políticas de acesso associadas à fila. Modifique a política de acesso que pretende alterar e, em seguida, chame Set Queue ACL
com o conjunto completo de dados para efetuar a atualização.
Estabelecer políticas de acesso armazenado
Uma política de acesso armazenado pode especificar a hora de início, a hora de expiração e as permissões para as assinaturas de acesso partilhado com as quais está associada. Consoante a forma como pretende controlar o acesso ao recurso de fila, pode especificar todos estes parâmetros na política de acesso armazenado e omiti-los a partir do URL da assinatura de acesso partilhado. Ao fazê-lo, pode modificar o comportamento da assinatura associada em qualquer altura ou revogá-lo. Em alternativa, pode especificar um ou mais parâmetros de política de acesso na política de acesso armazenado e os outros no URL. Por fim, pode especificar todos os parâmetros no URL. Neste caso, pode utilizar a política de acesso armazenado para revogar a assinatura, mas não para modificar o respetivo comportamento. Para obter mais informações sobre como estabelecer políticas de acesso, veja Definir uma política de acesso armazenado.
Em conjunto, a assinatura de acesso partilhado e a política de acesso armazenado têm de incluir todos os campos necessários para autorizar a assinatura. Se existirem campos necessários em falta, o pedido falhará. Da mesma forma, se for especificado um campo no URL de assinatura de acesso partilhado e na política de acesso armazenado, o pedido falha com o código de estado 400 (Pedido Incorreto).
No máximo, cinco políticas de acesso separadas podem ser definidas para uma única fila em qualquer altura. Se forem transmitidas mais de cinco políticas de acesso no corpo do pedido, o serviço devolve o código de estado 400 (Pedido Incorreto).
Quando estabelece uma política de acesso armazenado numa fila, pode demorar até 30 segundos a entrar em vigor. Durante este intervalo, uma assinatura de acesso partilhado associada à política de acesso armazenado falha com o código de estado 403 (Proibido), até que a política de acesso fique ativa.
Ver também
Definir uma política de acesso armazenada
Obter ACL de Fila
Autorizar pedidos para o Armazenamento do Azure
Códigos de estado e de erro