Definir ACL de Contentor

A Set Container ACL operação define as permissões para o contentor especificado. As permissões indicam se os blobs num contentor podem ser acedidos publicamente.

A partir da versão 2009-09-19, as permissões de contentor fornecem as seguintes opções para gerir o acesso ao contentor:

  • Acesso de leitura público completo: Os dados de contentores e blobs podem ser lidos através de um pedido anónimo. Os clientes podem enumerar blobs no contentor através de um pedido anónimo, mas não podem enumerar contentores na conta de armazenamento.

  • Acesso de leitura público apenas para blobs: Os dados de blobs neste contentor podem ser lidos através de um pedido anónimo, mas os dados de contentor não estão disponíveis. Os clientes não podem enumerar blobs no contentor através de um pedido anónimo.

  • Sem acesso público de leitura: Os dados de contentor e blob só podem ser lidos pelo proprietário da conta.

Set Container ACL também define uma política de acesso armazenada para utilização com assinaturas de acesso partilhado. Para obter mais informações, veja Definir uma política de acesso armazenado.

Todo o acesso público ao contentor é anónimo, tal como o acesso através de uma assinatura de acesso partilhado.

Pedir

O Set Container ACL pedido pode ser construído da 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.blob.core.windows.net/mycontainer?restype=container&comp=acl HTTP/1.1

Pedido de serviço de armazenamento emulado

Ao fazer um pedido contra o serviço de armazenamento emulado, especifique o nome do anfitrião do emulador e a porta do serviço Blob como 127.0.0.1:10000, seguido do nome da conta de armazenamento emulada:

Método URI do pedido Versão HTTP
PUT http://127.0.0.1:10000/devstoreaccount1/mycontainer?restype=container&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 Blob.

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-blob-public-access Opcional. Especifica se os dados no contentor podem ser acedidos publicamente e o nível de acesso. Valores possíveis incluem:

- container: especifica o acesso de leitura público completo para dados de contentores e blobs. Os clientes podem enumerar blobs no contentor através de um pedido anónimo, mas não podem enumerar contentores na conta de armazenamento.
- blob: Especifica o acesso de leitura público para blobs. Os dados de blobs neste contentor podem ser lidos através de um pedido anónimo, mas os dados de contentor não estão disponíveis. Os clientes não podem enumerar blobs no contentor através de um pedido anónimo.

Se este cabeçalho não estiver incluído no pedido, os dados de contentor são privados para o proprietário da conta.

Tenha em atenção que a definição de acesso público para um contentor numa conta do Azure Armazenamento Premium não é permitida.
x-ms-lease-id: <ID> Opcional, versão 2012-02-12 e posterior. Se for especificado, Set Container ACL só será bem-sucedido se a concessão do contentor estiver ativa e corresponder a este ID. Se não existir uma concessão ativa ou o ID não corresponder, será devolvido 412 (Falha na Pré-condição).
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 Armazenamento de Blobs do Azure.

Esta operação também suporta a utilização de cabeçalhos condicionais para executar a operação apenas se for cumprida uma condição especificada. Para obter mais informações, veja Especificar cabeçalhos condicionais para operações do serviço Blob.

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 Container 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.fffffffTZD

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 fffffff é a representação de sete dígitos de milissegundos. 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.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>  
  

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 200 (OK).

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
ETag O ETag para o contentor. Se a versão do pedido for 2011-08-18 ou posterior, o valor ETag estará entre aspas.
Last-Modified Devolve a data e hora em que o contentor foi modificado pela última vez. O formato de data segue RFC 1123. Para obter mais informações, veja Representar valores de data/hora em cabeçalhos.

Qualquer operação que modifique o contentor ou as respetivas propriedades ou metadados atualiza a hora da última modificação, incluindo a definição das permissões do contentor. As operações em blobs não afetam a hora da última modificação do contentor.
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 Blob que foi utilizada para executar o pedido. Este cabeçalho é devolvido para pedidos feitos 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 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 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  

Autorização

A Set Container ACL operação só suporta autorização de Chave Partilhada.

Observações

Apenas o proprietário da conta pode aceder a recursos num contentor específico, a menos que o proprietário tenha especificado que os recursos de contentor estão disponíveis para acesso público ao definir as permissões no contentor ou emitiu uma assinatura de acesso partilhado para um recurso no contentor.

Quando define permissões para um contentor, as permissões existentes são substituídas. Para atualizar as permissões do contentor, chame Obter ACL de Contentor para obter todas as políticas de acesso associadas ao contentor. Modifique a política de acesso que pretende alterar e, em seguida, chame Set Container ACL com o conjunto completo de dados para efetuar a atualização.

Ativar o acesso público anónimo em dados de contentor

Para ativar o acesso de leitura público anónimo em dados de contentor, chame Set Container ACL com o x-ms-blob-public-access cabeçalho definido como container ou blob. Para desativar o acesso anónimo, ligue Set Container ACL sem especificar o x-ms-blob-public-access cabeçalho.

Se definir x-ms-blob-public-access como blob, os clientes podem chamar as seguintes operações de forma anónima:

Se definir x-ms-blob-public-access como container, os clientes podem chamar as seguintes operações de forma anónima:

Estabelecer políticas de acesso ao nível do contentor

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 seu contentor ou recurso de blobs, 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, 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 um campo for especificado 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, podem ser definidas cinco políticas de acesso separadas para um único contentor 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).

Uma assinatura de acesso partilhado pode ser emitida num contentor ou num blob, independentemente de os dados de contentor estarem disponíveis para acesso de leitura anónimo. Uma assinatura de acesso partilhado fornece uma maior medida de controlo sobre como, quando e a quem um recurso é tornado acessível.

Nota

Quando estabelece uma política de acesso armazenado num contentor, a política pode demorar até 30 segundos a entrar em vigor. Durante este intervalo, até a política ficar ativa, uma assinatura de acesso partilhado associada à política de acesso armazenado falha com o código de estado 403 (Proibido).

Faturação

Os pedidos de preços podem ter origem em clientes que utilizam APIs de Armazenamento de Blobs, diretamente através da API REST do Armazenamento de Blobs ou a partir de uma biblioteca de cliente do Armazenamento do Azure. Estes pedidos acumulam custos por transação. O tipo de transação afeta a forma como a conta é cobrada. Por exemplo, as transações de leitura acumulam-se numa categoria de faturação diferente das transações de escrita. A tabela seguinte mostra a categoria de faturação dos Set Container ACL pedidos com base no tipo de conta de armazenamento:

Operação Tipo de conta de armazenamento Categoria de faturação
Definir ACL de Contentor Blob de bloco premium
Standard para fins gerais v2
Outras operações
Definir ACL de Contentor Standard para fins gerais v1 Operações de escrita

Para saber mais sobre os preços da categoria de faturação especificada, veja Armazenamento de Blobs do Azure Preços.

Ver também

Restringir o acesso a contentores e blobs
Delegar o acesso com uma assinatura de acesso partilhado
Criar e utilizar uma assinatura de acesso partilhado
Definir uma política de acesso armazenada
Obter ACL de Contentor
Autorizar pedidos para o Armazenamento do Azure
Códigos de estado e de erro
Códigos de erro do serviço blob