Set Queue ACL

Artikkel
06/27/2023

The Set Queue ACL operation sets stored access policies for the queue that may be used with a SAS (shared access signature). For more information, see Define a stored access policy.

Note

The Set Queue ACL operation is available in version 2012-02-12 and later.

Request

You can construct the Set Queue ACL request as follows. We recommend that you use HTTPS. Replace myaccount with the name of your storage account:

Method	Request URI	HTTP version
`PUT`	`https://myaccount.queue.core.windows.net/myqueue?comp=acl`	HTTP/1.1

Emulated storage service request

When you're making a request against the emulated storage service, specify the emulator hostname and Queue service port as 127.0.0.1:10001, followed by the emulated storage account name:

Method	Request URI	HTTP version
`PUT`	`http://127.0.0.1:10001/devstoreaccount1/myqueue?comp=acl`	HTTP/1.1

For more information, see Use the Azurite emulator for local Azure Storage development.

URI parameters

You can specify the following additional parameters on the request URI:

Parameter	Description
`timeout`	Optional. The `timeout` parameter is expressed in seconds. For more information, see Set time-outs for Queue service operations.

Request headers

The required and optional request headers are described in the following table:

Request header	Description
`Authorization`	Required. Specifies the authorization scheme, account name, and signature. For more information, see Authorize requests to Azure Storage.
`Date` or `x-ms-date`	Required. Specifies the Coordinated Universal Time (UTC) for the request. For more information, see Authorize requests to Azure Storage.
`x-ms-version`	Optional. Specifies the version of the operation to use for this request. For more information, see Versioning for the Azure Storage services.
`x-ms-client-request-id`	Optional. Provides a client-generated, opaque value with a 1-kibibyte (KiB) character limit that's recorded in the logs when logging is configured. We highly recommend that you use this header to correlate client-side activities with requests that the server receives. For more information, see Monitor Azure Queue Storage.

Request body

To specify a stored access policy, provide a unique identifier and access policy in the request body for the Set Queue ACL operation.

The SignedIdentifier element includes the unique identifier, as specified in the Id element, and the details of the access policy, as specified in the AccessPolicy element. The maximum length of the unique identifier is 64 characters.

The Start and Expiry fields must be expressed as UTC times and must adhere to a valid ISO 8061 format. Supported ISO 8061 formats include the following:

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

For the date portion of these formats, YYYY is a four-digit year representation, MM is a two-digit month representation, and DD is a two-digit day representation. For the time portion, hh is the hour representation in 24-hour notation, mm is the two-digit minute representation, ss is the two-digit second representation, and ffffff is the six-digit millisecond representation. A time designator T separates the date and time portions of the string, and a time zone designator TZD specifies a time zone.

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

Response

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

Status code

A successful operation returns status code 204 (No Content).

For more information about status codes, see Status and error codes.

Response headers

The response for this operation includes the following headers. The response may also include additional standard HTTP headers. All standard headers conform to the HTTP/1.1 protocol specification.

Response header	Description
`x-ms-request-id`	Uniquely identifies the request that was made and can be used to troubleshoot the request. For more information, see Troubleshoot API operations.
`x-ms-version`	Indicates the Queue service version that was used to execute the request. This header is returned for requests that were made against version 2009-09-19 and later.
`Date`	A UTC date/time value that's generated by the service, which indicates the time when the response was initiated.
`x-ms-client-request-id`	This header can be used to troubleshoot requests and corresponding responses. The value of this header is equal to the value of the `x-ms-client-request-id` header if it's present in the request and the value contains no more than 1,024 visible ASCII characters. If the `x-ms-client-request-id` header isn't present in the request, it won't be present in the response.

Sample response

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

Authorization

Only the account owner may call this operation.

Remarks

Only the account owner may access resources in a particular queue unless the owner has issued a shared access signature for a resource within the queue.

When you set permissions for a queue, the existing permissions are replaced. To update the queue’s permissions, call Get Queue ACL to fetch all access policies that are associated with the queue. Modify the access policy that you want to change, and then call Set Queue ACL with the complete set of data to perform the update.

Establish stored access policies

A stored access policy can specify the start time, expiration time, and permissions for the shared access signatures with which it's associated. Depending on how you want to control access to your queue resource, you can specify all of these parameters within the stored access policy, and omit them from the URL for the shared access signature. By doing so you can modify the associated signature's behavior at any time or revoke it. Or you can specify one or more access policy parameters within the stored access policy, and the others on the URL. Finally, you can specify all the parameters on the URL. In this case, you can use the stored access policy to revoke the signature, but not to modify its behavior. For more information about establishing access policies, see Define a stored access policy.

Together, the shared access signature and the stored access policy must include all fields that are required to authorize the signature. If any required fields are missing, the request fails. Likewise, if a field is specified both in the shared access signature URL and in the stored access policy, the request fails with status code 400 (Bad Request).

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

When you establish a stored access policy on a queue, it might take up to 30 seconds to take effect. During this interval, a shared access signature that's associated with the stored access policy fails with status code 403 (Forbidden), until the access policy becomes active.

Del via