Set Container ACL (REST API)

The Set Container ACL request may be constructed as follows. HTTPS is recommended. Replace myaccount with the name of your storage account:

Emulated Storage Service URI

URI Parameters

Request Headers

Request Body

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

Sample Request

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>

The response includes an HTTP status code and a set of response headers.

Status Code

Response Headers

Sample Response

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

Only the account owner may call this operation.

Only the account owner may access resources in a particular container, unless the owner has specified that container resources are available for public access by setting the permissions on the container, or has issued a Shared Access Signature for a resource within the container.

When you set permissions for a container, the existing permissions are replaced. To update the container's permissions, call Get Container ACL (REST API) to fetch all access policies associated with the container, modify the access policy that you wish to change, and then call Set Container ACL with the complete set of data to perform the update.

Enabling Anonymous Public Access on Container Data

To enable anonymous public read access on container data, call Set Container ACL with the x-ms-blob-public-access header set to container or blob. To disable anonymous access, call Set Container ACL without specifying the x-ms-blob-public-access header.

If you set x-ms-blob-public-access to blob, clients can call the following operations anonymously:

• Get Blob (REST API)
  
  
• Get Blob Properties (REST API)
  
  
• Get Blob Metadata (REST API)
  
  
• Get Block List (REST API) (for the committed block list only)
  
  
• Get Page Ranges (REST API)
  
  

If you set x-ms-blob-public-access to container, clients can call the following operations anonymously:

• The blob access operations listed above.
  
  
• Get Container Properties (REST API)
  
  
• Get Container Metadata (REST API)
  
  
• List Blobs (REST API)
  
  

Establishing Container-Level Access Policies

A container-level access policy can specify the start time, expiry time, and permissions for the Shared Access Signatures with which it's associated. Depending on how you want to control access to your container or blob resource, you can specify all of these parameters within the container-level access policy, and omit them from the URL for the Shared Access Signature. Doing so permits you to modify the associated signature's behavior at any time, as well as to revoke it. Or you can specify one or more of the access policy parameters within the container-level access policy, and the others on the URL. Finally, you can specify all of the parameters on the URL. In this case, you can use the container-level access policy to revoke the signature, but not to modify its behavior. See specifying a Use a Stored Access Policy for more information about establishing access policies.

Together the Shared Access Signature and the container-level access policy must include all fields required to authenticate the signature. If any required fields are missing, the request will fail. Likewise, if a field is specified both in the Shared Access Signature URL and in the container-level access policy, the request will fail with status code 400 (Bad Request). See Create a Shared Access Signature for more information about the fields that comprise a Shared Access Signature.

Note that at most five separate access policies can be set for a given container at any time. If more than five access policies are passed in the request body, then the service returns status code 400 (Bad Request).

Note that a Shared Access Signature can be issued on a container or a blob regardless of whether container data is available for anonymous read access. A Shared Access Signature provides a greater measure of control over how, when, and to whom a resource is made accessible.

Reference

Concepts

Other Resources