如果我设置我的应用程序生成预签名URL以访问S3媒体文件(这样我就可以将文件设置为私有,除非通过已登录的用户访问),那么如果某人在过期时间内拥有URL访问权限,他们可以看到该文件,尽管它是“私有”的,你认为我的理解正确吗?
所以,如果有人向别人发送URL,那么它就不再是私有的了。
我想没有其他方法,但这对我来说似乎很奇怪。
所以,如果有人向别人发送URL,那么它就不再是私有的了。
我想没有其他方法,但这对我来说似乎很奇怪。
是的,您说得对,签名URL可以被“共享”,因为它在到期之前有效(或者在签名它的凭据到期或无效时,以先到者为准)。
一种常见的解决方案是在页面呈现时,您的应用程序生成带有非常短过期时间的签名URL。
另一种解决方案是将安全内容的链接实际上作为返回到应用程序的链接,该应用程序验证用户访问对象的权限,然后返回一个HTTP重定向到具有短过期时间(例如5秒)的新生成的签名URL。
HTTP/1.1 302 Found
Location: https://example-bucket.s3.amazonaws.com/...?X-Amz-...
签名 URL 无法被当前可行的计算能力篡改,因此恶意用户修改签名 URL 在实际上是不切实际甚至不可能的。
还要注意的是,签名 URL(无论是 S3 还是 CloudFront)仅在下载 开始 时需要未过期。下载实际上完成所需的时间可以任意长,且下载不会中断。
以下选项没有现成的服务,但是通过使用 CloudFront Lambda@Edge 触发器和 DynamoDB 的组合,可以创建一个真正的一次性 URL,其中包含在 Dynamo 表中存储的随机生成的“令牌”,并与目标对象相关联。当访问该 URL 时,您可以在 Lambda 触发器中使用 DynamoDB 条件更新将(例如)“view_count”值从 0 更新为 1。如果表中不存在该令牌或查看计数不为 0,则条件更新失败,因此拒绝访问;否则,CloudFront 允许请求继续进行 - 正好一次。CloudFront 使用 Origin Access Identity 访问 S3 内容,所有这些都在幕后完成,因此与 CloudFront 和 S3 之间的实际身份验证相关的任何内容都无法被用户访问。(对于加密质量的随机令牌生成,您还可以使用 KMS 的GenerateRandom
API 操作。)/images/*
),没有任何防止用户共享其cookie的方法,因此对于您的用例可能没有用处。这仍然是一个单独的用户请求内容。对于一个单独的用户,证书将不再有效。
来源: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-signed-urls.html
GET
请求URL都不会导致服务检查任何标头。 - Michael - sqlbot