预先签署的网址和x-amz-acl [英] Pre-signed URLs and x-amz-acl

问题描述

我想创建一个所谓的预签名" URL，以将特定对象(PUT)上传到Amazon S3存储桶.

到目前为止，一切都很好.我正在使用python库 boto 创建一个URL，其中包含所有必要的内容(过期，签名等).网址看起来像这样:

https://<bucketname>.s3.amazonaws.com/<key>?Signature=<sig>&Expires=<expires>&AWSAccessKeyId=<my key id>&x-amz-acl=public-read

注意最后一个参数.

至少，据我了解，这限制了使用此URL的任何人将对象上传到特定存储桶中的特定键，并且还将将在该对象上设置的罐头ACL限制为公开读取"./p>

我的上一句话虽然很不正确.

事实证明，如果您使用的是此URL，则可以使用x-amz-acl 标头(与查询字符串参数相反)执行以下操作您必须 设置相同的名称，签名检查才能成功):

1. 将其设置为公开阅读".对象的权限将包含两个条目:所有人"的读取"和存储桶拥有者的完全控制".这是完全可以预期的.
2. 省略x-amz-acl标头.该对象的权限将与每个存储桶的默认权限相同(存储桶拥有者拥有完全控制权).为什么?
3. 将其设置为"public-read-write".结果与(1)完全相同.
4. 将其设置为已验证身份". 授权用户"获得读取"权限，存储桶拥有者拥有完全控制权.
5. 将其设置为"bucket-owner-read".结果与(2)完全相同.值区拥有者拥有完全控制权，未定义其他权限.
6. 将其设置为"bucket-owner-full-control".毫不奇怪，存储桶拥有者将拥有完全控制权.
7. 将其设置为不存在的罐头ACL名称，并收到错误消息.

看来，

1. x-amz-acl 标头不参与签名检查，因为您可以随意更改它，并且请求成功.但是，在签名检查期间肯定会考虑查询字符串参数.
2. x-amz-acl 查询字符串参数不会直接影响对象的权限 ，因为它本身不会执行任何操作.
3. 如果发送x-amz-acl标头，则永远不会
   • 对存储桶拥有者的限制比默认情况下要严格.
   为非存储桶所有者提供
   • less restricvie.
4. 但是，对于非存储桶拥有者，它们可以更具限制性.也就是说，如果您在查询字符串中指定x-amz-acl=public-read，则可以将x-amz-acl标头设置为authenticated-read，而不是公共可读的对象获取一个对象，该对象只能由经过身份验证的用户读取.

x-amz-acl QS参数和标头之间的 real 关系是什么?是否有一种方法可以限制对象的权限，该对象是通过PUT请求上传到所谓的预签名" URL的?

解决方案

据我了解(这里我可能是错的)，标头x-amz-acl优先于querystring参数，并且它们的作用相同.在签名检查期间仅考虑querystring参数的原因仅是因为标头不是该策略的签名检查的一部分.

此页面可能会对您有所帮助；在创建直接上载到S3的表单时，对我有很大帮助.

I want to create a so-called "pre-signed" URL for uploading a particular object (PUT) to Amazon S3 bucket.

So far so good. I am using the python library boto to create an URL, that contains all necessary stuff (expires, signature and so on). The URL looks like this:

https://<bucketname>.s3.amazonaws.com/<key>?Signature=<sig>&Expires=<expires>&AWSAccessKeyId=<my key id>&x-amz-acl=public-read

Note the last parameter.

This, at least, as I understand, limits whoever uses this URL to uploading an object to a particular key in a particular bucket and also limits the canned ACL that will be set on the object to "public-read".

My last statement is quite incorrect though.

As it turns out, if you are using this URL, you can do the following with the x-amz-acl header (as opposed to the query string parameter with the same name, that you must set for the signature check to succeed):

1. Set it to "public-read". The object's permissions will consist of two entries: "read" for "Everyone" and "full control" for bucket owner. This is quite expected.
2. Omit the x-amz-acl header. The permissions on the object will be the same as the per-bucket default (bucket owner has full control). Why?
3. Set it to "public-read-write". Result is exactly as in (1).
4. Set it to "authenticated-read". "Authenticated users" get "read" permission, bucket owner has full control.
5. Set it to "bucket-owner-read". Result is exactly as in (2). Bucket owner has full control, no other permissions are defined.
6. Set it to "bucket-owner-full-control". Unsurprisingly, bucket owner will have full control.
7. Set it to a non-existant canned ACL name and get an error.

So it seems, that

1. The x-amz-acl header does not take part in the signature check, because you can change it at will and the request succeeds. The query string parameter, however, definitely is taken into account during the signature check.
2. x-amz-acl query string parameter does not influence the object's permissions directly, as in, it does nothing on its own.
3. If you send a x-amz-acl header, the resultant permissions never be
   • more restrictive for the bucket owner, than they are by default.
   • less restricvie for the non-bucket-owner.
4. They can, however, be more restrictive for non-bucket-owner. That is, if you specify x-amz-acl=public-read in the query string, you can set the x-amz-acl header to authenticated-read and instead of a publicly readable object get an object, that can be only read by authenticated users.

What is the real relation between the x-amz-acl QS parameter and the header, that goes by the same name? Is there a way to restrict permissions on the object, that is to be uploaded via a PUT request to a so-called "pre-signed" URL?

解决方案

As I understand it (and I might be wrong here), the header x-amz-acl takes priority over the querystring argument--and they do serve the same purpose. The reason that only the querystring parameter is taken into account during the signature check is simply due to the fact that headers are not part of the signature check for the policy.

This page might help you; it helped me a lot when creating forms to upload directly to S3.

这篇关于预先签署的网址和x-amz-acl的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！