使用预先签名的URL进行AWS S3身份验证的用户访问？

Question

我想将文件托管在私有AWS S3存储桶中，该存储桶只能由经过我的Web应用程序身份验证的用户访问。 这些文件下载的链接必须是静态的。

简单的代理方法：

我知道可以使用代理服务来完成。 在这种情况下，静态链接将指向该服务，并且该服务将处理验证请求用户的会话，如果有效，该服务将使用来自S3的文件内容进行响应。

预设URL代理方法：

但是，我没有实现代理来控制对文件的访问，而是想知道是否可以以某种方式使用预签名的URL？

https://docs.aws.amazon.com/AmazonS3/latest/dev/ShareObjectPreSignedURL.html

在这种情况下，代理的作用只是向用户返回一个预签名的URL，而不是从S3返回文件的实际有效负载。 然后，最终用户可以使用此预签名URL直接从S3下载文件。 我尚不清楚的是如何在浏览器中管理此流程，我假设我需要将JavaScript编写为以下内容：

1. 从代理服务请求预签名的URL
2. 等待回应
3. 使用响应中提供的预签名URL（预签名URL）下载实际文件

我在正确的轨道上吗？

Answer 1

只需将307重定向从您的服务器返回到预先签名的URL。 例如客户要求：

GET /the/file HTTP/1.1

然后服务器生成一个预签名的URL并响应：

HTTP/1.1 307 Temporary Redirect
Location: https://s3.aws..../the/file?...

Answer 2

这是一种有效的方法。

当心过期的凭据。 在用于签名的URL到期或它们的到期时间（由您控制​​，在限制范围内）发生之前，签名的URL在较短的时间内会比较有用。 如果您已经在使用临时凭证（这非常好！），则可能需要显式使用AssumeRole来控制到期时间（您可以从角色中假设一个角色，以获得具有新时间限制的新临时凭证） 。

还有另一种选择：Amazon Cognito。 这样可以弥合用户帐户之间的鸿沟，然后直接向用户的浏览器环境颁发每用户的短期凭据。 然后，他们可以使用自己的凭据对S3进行API调用。 这有一些好处（您可以更好地在用户个人资料中表达用户权限，而不是在用户生成URL之前先进行检查）和一些复杂性（我可以使用用户凭据来对您的帐户进行操作，还是可以控制我可以调用的API？当IAM是您唯一的身份验证层时，特权确实很重要。）另一方面，IAM呼叫是免费的，您无需为托管它们的服务器付费，因此，如果您使用联合身份验证，那么这听起来很划算-用户池，而不是许多。