最佳实践围绕使用 S3 作为具有数据库的应用程序的文件存储

Question

我认为使用 S3 兼容来为应用程序资产或“附件”进行文件存储是最常见的用例之一，但我看到了一些问题，但我不清楚如何解决。

如果您要提供一个可以缓存的前端或纯粹的 HTML/JS 项目，很明显您可以使用存储（+ CDN）来托管它，但是当存储来自用户的文件时，我看到选项是：

只有应用程序有权访问存储桶，并对所请求的资源进行“传递”。
应用程序具有写入访问权限，但读取权限是公共的，这意味着应用程序接收资源并将其存储到存储桶中，客户端从应用程序获取引用以识别存储桶上的资源。
应用程序通过设置 OpenID 类型的模型或提供短期令牌来访问给定对象来管理访问，并且客户端在应用程序的明确许可下并通过获取要进行交易的正确引用来执行所有操作。

我认为简单的方法是使用选项 2，我见过 FOSS 项目在支持 S3 兼容存储时就这样做。

但我不确定什么是好的决定标准。

我看到的主要问题是，使用方法 1 允许应用程序对客户端透明，同时在请求多个文件时引入可能的瓶颈。

关于第三点，听起来太复杂，无法在 POC 中实现。

关于这种情况的最佳实践有什么想法或评论吗？

Answer 1

使用方法 #3。

您可以使用Amazon S3 预签名 URL，它提供对 Amazon S3 中私有对象的限时访问。

基本上：

对象保存在私有存储桶中。只有应用程序可以访问对象。
当应用程序确定用户有权查看文件时，它会生成一个预签名 URL。这可以通过几行代码完成，并且不需要对 AWS 进行 API 调用（它基本上计算哈希作为“签名”来授权访问）。
用户收到一个链接。单击或使用时，会向 S3 发送正常的 HTTP/S 请求。
S3验证签名是否正确并且到期时间尚未到期。如果一切正常，则返回该对象，就像该对象是公共对象一样。

因此，您的应用程序有责任对用户进行身份验证并确定他们有权访问哪些对象。它生成预签名 URL并将其提供给用户。然后，预签名的 URL 可以用作链接，甚至可以在<img src="...">引用中使用。