为什么CloudFront仅在授予列表权限时才返回自定义错误对象? [英] Why CloudFront returns custom error object only when List permission is granted?

查看:99
本文介绍了为什么CloudFront仅在授予列表权限时才返回自定义错误对象?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我注意到,如果未将存储桶的列表权限授予公众,则CloudFront的自定义错误页面(在我的情况下为404)始终返回403禁止。授予列表权限后,便可以返回自定义404图像。

I noticed that if the list permission of the bucket is not granted to the public, CloudFront's custom error page (404 not found in my case) always returns 403 forbidden. Once the list permission is granted, a custom 404 image is able to be returned.

我的所有对象均未明确标记为公开可读。但我已授予存储区中所有对象的CloudFront原始身份读取权限。因此,我假设,当CloudFront尝试获取不存在的对象时,它找不到它。然后尝试列出所有对象以找到目标;因此,该权限被拒绝。这部分使我感到困惑。如果目标存在时不需要列表权限,为什么CloudFront在第一步中找不到原始目标时为什么不抓住特定的自定义错误对象?

None of my objects are explicitly marked as publicly readable. But I have given CloudFront origin identity read permission for all objects in the bucket. So I assume, when CloudFront tries to grab the non-existent object, it can't find it; then it tries to list all objects to find the target; consequently, the permission is denied. This part confuses me. If list permission is not needed when targets exist, why wouldn't CloudFront just grab the given custom error object when it can't find the original target in the first step? Is listing objects just to confirm a 404 status?

推荐答案

当Cloudfront尝试访问不存在的对象时,403直接来自S3。没有列表权限的密钥。 Cloudfront不会尝试再次请求列出对象或类似对象。当Cloudfront尝试访问不存在的对象时,S3只是直接返回403。

The 403 comes directly from S3 when Cloudfront tries to access a non-existent key without having list permissions. Cloudfront isn't trying to make a second request to list the objects, or anything like that. S3 just directly returns a 403 when Cloudfront tries to access a non-existing object.

当您尝试访问不存在的对象时,S3返回403响应而不是404的原因。 -没有列表权限的现有密钥是,没有列表权限,您将无法区分这两种情况:

The reason S3 returns a 403 response and not a 404 when you try to access a non-existent key without the list permission is that without the permission you should not be able to distinguish between these two scenarios:


  1. S3密钥存在但权限不允许访问该对象

  2. S3密钥不存在

如果可以通过枚举可能的键并检查403和404响应来区分可以有效列出存储桶内容的对象。没有列表许可权是不允许的,因此这两种情况必须彼此具有相同的响应才能区分。它们都可以是403或都可以是404,但是403更适合,因为它表示禁止。没有列表权限,您将禁止知道该键是否存在某个元素。

If you could distinguish those you could effectively list the contents of the bucket by enumerating likely keys and checking for 403 vs 404 responses. That is not allowed without the list permissions, so those two scenarios must have the same response as each other to be indistinguishable. They could both be 403 or both be 404, but 403 is more fitting as it represents "Forbidden". Without the list permission, you are "Forbidden" from knowing whether there is an element existing with that key or not.

这并不真正适用于所有情况存储桶中的对象是可访问的,但是如果存储桶中只有一个对象是秘密的,并且您不希望没有列表权限的人知道它存在,您将不满意S3通过返回403来揭示它的存在。该特定网址的404代码。 S3的规则适用于无法确定存储桶中的所有对象都可以访问甚至无法检测到它们存在的一般情况。

It doesn't really apply to your case where all the objects in the bucket are accessible, but if you had just one object in your bucket that is secret and you don't want people without the list permission to know it is there you would appreciate S3 not revealing it's existence by returning a 403 instead of a 404 for that one specific url. S3's rules are applicable to the general case where it isn't certain that all the objects in the bucket are accessible or even that their existence should be detectable.

这篇关于为什么CloudFront仅在授予列表权限时才返回自定义错误对象?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆