Amazon S3 在这种情况下有什么帮助吗？
我正在考虑是否将上传的媒体文件（视频和音频）托管在 S3 上而不是本地。我需要检查每次下载的用户权限。
因此会有像 get_file 这样的操作，它首先检查用户的权限，然后从 S3 获取文件并使用 send_file 将其发送给用户。
def get_file
if @user.can_download(params[:file_id])
# first, download the file from S3 and then send it to the user using send_file
end
end
但在这种情况下，服务器（不必要）首先从 S3 下载文件，然后将其发送给用户。我认为 S3 的用例是绕过 Rails/HTTP 服务器堆栈以减少负载。
我这样想有错吗？
附言。我正在使用 CarrierWave 进行文件上传。不确定这是否相关。
I'm thinking about whether to host uploaded media files (video and audio) on S3 instead of locally. I need to check user's permissions on each download.
So there would be an action like get_file, which first checks the user's permissions and then gets the file from S3 and sends it using send_file to the user.
def get_file
if @user.can_download(params[:file_id])
# first, download the file from S3 and then send it to the user using send_file
end
end
But in this case, the server (unnecessarily) downloads the file first from S3 and then sends it to the user. I thought the use case for S3 was to bypass the Rails/HTTP server stack for reduced load.
Am I thinking this wrong?
PS. I'm using CarrierWave for file uploads. Not sure if that's relevant.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
Amazon S3 提供了一种称为 RESTful 身份验证读取的功能，它基本上是受保护内容的超时 URL。
CarrierWave 对此提供了支持。只需将 S3 访问策略声明为经过身份验证的读取：
，然后
model.file.url将自动生成 RESTful URL。Amazon S3 provides something called RESTful authenticated reads, which are basically timeoutable URLs to otherwise protected content.
CarrierWave provides support for this. Simply declare S3 access policy to authenticated read:
and then
model.file.urlwill automatically generate the RESTful URL.通常，您会在页面中嵌入 S3 URL，以便客户端的浏览器直接从 Amazon 获取文件。但请注意，这会暴露原始的未受保护的 URL。您可以使用长哈希值而不是可预测的名称来命名该文件，因此它至少是不可猜测的 - 但一旦该 URL 公开，它基本上就向 Internet 开放。因此，如果您绝对总是需要对文件进行访问控制，那么您需要像当前所做的那样对其进行代理。在这种情况下，您可能会决定将文件存储在本地更好。
Typically you'd embed the S3 URL in your page, so that the client's browser fetches the file directly from Amazon. Note however that this exposes the raw unprotected URL. You could name the file with a long hash instead of something predictable, so it's at least not guessable -- but once that URL is exposed, it's essentially open to the Internet. So if you absolutely always need access control on the files, then you'll need to proxy it like you're currently doing. In that case, you may decide it's just better to store the file locally.