import { EndpointParameterInstructions } from "@aws-sdk/middleware-endpoint"; import { Command as $Command } from "@aws-sdk/smithy-client"; import { Handler, HttpHandlerOptions as __HttpHandlerOptions, MetadataBearer as __MetadataBearer, MiddlewareStack } from "@aws-sdk/types"; import { PutObjectAclOutput, PutObjectAclRequest } from "../models/models_0"; import { S3ClientResolvedConfig, ServiceInputTypes, ServiceOutputTypes } from "../S3Client"; /** * @public * * The input for {@link PutObjectAclCommand}. */ export interface PutObjectAclCommandInput extends PutObjectAclRequest { } /** * @public * * The output of {@link PutObjectAclCommand}. */ export interface PutObjectAclCommandOutput extends PutObjectAclOutput, __MetadataBearer { } /** * @public *
Uses the acl subresource to set the access control list (ACL) permissions
* for a new or existing object in an S3 bucket. You must have WRITE_ACP
* permission to set the ACL of an object. For more information, see What
* permissions can I grant? in the Amazon S3 User Guide.
This action is not supported by Amazon S3 on Outposts.
*Depending on your application needs, you can choose to set * the ACL on an object using either the request body or the headers. For example, if you have * an existing application that updates a bucket ACL using the request body, you can continue * to use that approach. For more information, see Access Control List (ACL) Overview in the Amazon S3 User Guide.
*If your bucket uses the bucket owner enforced setting for S3 Object Ownership, ACLs are disabled and no longer affect permissions.
* You must use policies to grant access to your bucket and the objects in it. Requests to set ACLs or update ACLs fail and
* return the AccessControlListNotSupported error code. Requests to read ACLs are still supported.
* For more information, see Controlling object ownership
* in the Amazon S3 User Guide.
* Access Permissions *
*You can set access permissions using one of the following methods:
*Specify a canned ACL with the x-amz-acl request header. Amazon S3 supports
* a set of predefined ACLs, known as canned ACLs. Each canned ACL has a predefined set
* of grantees and permissions. Specify the canned ACL name as the value of
* x-amz-acl. If you use this header, you cannot use other access
* control-specific headers in your request. For more information, see Canned ACL.
Specify access permissions explicitly with the x-amz-grant-read,
* x-amz-grant-read-acp, x-amz-grant-write-acp, and
* x-amz-grant-full-control headers. When using these headers, you
* specify explicit access permissions and grantees (Amazon Web Services accounts or Amazon S3 groups) who
* will receive the permission. If you use these ACL-specific headers, you cannot use
* x-amz-acl header to set a canned ACL. These parameters map to the set
* of permissions that Amazon S3 supports in an ACL. For more information, see Access Control List (ACL)
* Overview.
You specify each grantee as a type=value pair, where the type is one of the * following:
*
* id – if the value specified is the canonical user ID of an Amazon Web Services account
* uri – if you are granting permissions to a predefined
* group
* emailAddress – if the value specified is the email address of
* an Amazon Web Services account
Using email addresses to specify a grantee is only supported in the following Amazon Web Services Regions:
*US East (N. Virginia)
*US West (N. California)
*US West (Oregon)
*Asia Pacific (Singapore)
*Asia Pacific (Sydney)
*Asia Pacific (Tokyo)
*Europe (Ireland)
*South America (São Paulo)
*For a list of all the Amazon S3 supported Regions and endpoints, see Regions and Endpoints in the Amazon Web Services General Reference.
*For example, the following x-amz-grant-read header grants list
* objects permission to the two Amazon Web Services accounts identified by their email
* addresses.
* x-amz-grant-read: emailAddress="xyz@amazon.com",
* emailAddress="abc@amazon.com"
*
You can use either a canned ACL or specify access permissions explicitly. You cannot do * both.
** Grantee Values *
*You can specify the person (grantee) to whom you're assigning access rights (using * request elements) in the following ways:
*By the person's ID:
*
*
*
DisplayName is optional and ignored in the request.
*By URI:
*
*
*
By Email address:
*
*
*
The grantee is resolved to the CanonicalUser and, in a response to a GET Object * acl request, appears as the CanonicalUser.
*Using email addresses to specify a grantee is only supported in the following Amazon Web Services Regions:
*US East (N. Virginia)
*US West (N. California)
*US West (Oregon)
*Asia Pacific (Singapore)
*Asia Pacific (Sydney)
*Asia Pacific (Tokyo)
*Europe (Ireland)
*South America (São Paulo)
*For a list of all the Amazon S3 supported Regions and endpoints, see Regions and Endpoints in the Amazon Web Services General Reference.
** Versioning *
*The ACL of an object is set at the object version level. By default, PUT sets the ACL of
* the current version of an object. To set the ACL of a different version, use the
* versionId subresource.
* Related Resources *
** CopyObject *
** GetObject *
*The specified key does not exist.
* * * @example To grant permissions using object ACL * ```javascript * // The following example adds grants to an object ACL. The first permission grants user1 and user2 FULL_CONTROL and the AllUsers group READ permission. * const input = { * "AccessControlPolicy": {}, * "Bucket": "examplebucket", * "GrantFullControl": "emailaddress=user1@example.com,emailaddress=user2@example.com", * "GrantRead": "uri=http://acs.amazonaws.com/groups/global/AllUsers", * "Key": "HappyFace.jpg" * }; * const command = new PutObjectAclCommand(input); * await client.send(command); * // example id: to-grant-permissions-using-object-acl-1481835549285 * ``` * */ export declare class PutObjectAclCommand extends $Command