PUT Bucket ACL

Description

This PUT operation uses the 'ACL' resource to set access permissions for the existing user space through the access permission list.

Currently, only the bucket owner has this permission

You can use the following two ways to set object permissions.

• Specify 'ACL' in the request body.
• Use the request header to set access rights.

Note: The above two methods cannot be used at the same time.

Request

Grammar

The following shows how to set by specifying 'ACL' in the request body.

PUT /?acl HTTP/1.1
Host: {BucketName}.{endpoint}
Date: {date}
Authorization: {SignatureValue}

<AccessControlPolicy>
  <Owner>
    <ID>{ID}</ID>
    <DisplayName>{EmailAddress}</DisplayName>
  </Owner>
  <AccessControlList>
    <Grant>
      <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="CanonicalUser">
        <ID>{ID}</ID>
        <DisplayName>{EmailAddress}</DisplayName>
      </Grantee>
      <Permission>{Permission}</Permission>
    </Grant>
    ...
  </AccessControlList>
</AccessControlPolicy>

Note:

• Corresponding relationship between Endpoint and Region
• SignatureValue signature algorithm

Request parameters

The interface does not use request parameters.

Request header

The interface can use all common request headers. For more information, please click Public request headers. The user can set the preset ACL for bucket through the following headers.

If you want to set the detailed ACL for the bucket, you can use the following header settings

The value of the above header value is a comma separated authorization list. The format of each authorization information is type = value. The current type supports ID:

• ID: user ID of the authorized person

For example, to grant WRITE permission to two users with ID 1234578 and 3344211: x-kss-grant-write:id="1234578",id="3344211"

Request content

If the user decides to use the request body to specify the access list, the following table element is required.

Note: If you use the request body to set ACL, you can no longer set ACL through the request header.

The way of granting permission

Users can grant a user permission to the user space in the following way.

Specific user rights are granted based on user ID

Response

Response header

This interface can use all common response headers. For more information, please click Public response headers.

Response content

The interface does not return the corresponding content.

Special errors

The interface does not return any special errors.

Example

Request example

PUT /?acl HTTP/1.1
Host: ks3-example.ks3-cn-beijing.ksyuncs.com
Content-Length: 1660
Date: Fri, 26 Dec 2014 06:34:32 GMT
Authorization: authorization string

<AccessControlPolicy xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
<Owner>
<ID>73410125</ID>
<DisplayName>[email protected]</DisplayName>
</Owner>
<AccessControlList>
<Grant>
<Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="CanonicalUser">
<ID>73410125</ID>
<DisplayName>[email protected]</DisplayName>
</Grantee>
<Permission>FULL_CONTROL</Permission>
</Grant>
<Grant>
<Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="CanonicalUser">
<ID>73410125</ID>
<DisplayName>[email protected]</DisplayName>
</Grantee>
<Permission>READ</Permission>
</Grant>
</AccessControlList>
</AccessControlPolicy>

Response example

HTTP/1.1 200 OK
Date: Fri, 26 Dec 2014 06:34:32 GMT
x-kss-request-id: dbea4ce4ec23415b9e454ecfa25ec4d9
Content-Length: 0
Server: Tengine

Interface details

• Please refer to ACL for the meaning of bucket permission .
• When ACL is set in the header and body at the same time, only those in the header will take effect. When both x-kss-acl and x-kss-grant-* are set in the header, the latter takes effect.
• For most users, using x-kss-acl to set the preset ACL in the header can meet most requirements. For bucket, you usually need to set x-kss-acl to private.