问题在于，CDN 出现了错误的行为，而这正是你明确不希望看到的。只有非 CDN 能正常工作，即当你点击“下载”时，确实会下载某些内容。
啊，好的，那我们应该修复一下。
说得对。有没有自定义灯箱的示例可以供我作为起点？
根据以下内容，这根本不容易被黑客攻击：
您需要阅读 https://dimsemenov.com/plugins/magnific-popup/，看看它是否可以在运行时以某种方式重新配置。
真遗憾，我看看能不能想出什么办法。
只是出于好奇——为什么 Discourse 在这里选择“下载”操作而不是“查看原图”？从用户的角度来看，查看原图似乎更常见？
我原以为这是一个 MIME 问题，但查看头部信息后，可能是：
x-download-options: noopen
这会阻止文件在下载时被打开。希望 Sam 能澄清一下。
这应该是 @codinghorror 的决定。我想这是一种能干净地保留原始上传文件名的方法，而有些人很在意这一点。此外，这看起来也是 Flickr 的做法。
我认为我们不会改动任何相关内容。我们只需让应用通过专用路由来代理这些请求即可。毕竟点击“下载”的人数微乎其微，因此在此处绕过 CDN 可能是可以接受的。无论如何，@pmusaraj 会确定最佳方案。据我了解，我们要么需要让 AWS 提供一个带有特殊内容处置（content disposition）的签名 URL，要么需要代理该文件。这两种情况都涉及绕过 S3 CDN。如果我们通过应用进行代理，至少可以利用应用的 CDN。
再读了一些资料后发现，content-disposition: attachment; 和 x-download-options: noopen 导致了这一行为。
理解这只是“如何”发生，而非“为何”发生。但如果是出于安全考虑，那就完全合理了。
此 PR 应能通过以下方式修复此问题：
- 当启用 S3 上传时，为灯箱下载链接添加
data-download-href属性 - 使用的 URL 是带有
dl=1参数的新短 URL 方案，这将使控制器生成带有正确内容处置（content disposition）和文件名的预签名 S3 URL
换句话说，灯箱中的下载链接现在将类似于 /uploads/short-url/mTGbg4Ld2iBYAbfTvEjGXP2LtVm.pdf?dl=1，该链接将重定向到带有 content-disposition: "attachment; filename=original.png" 的签名 S3 URL。
我认为这是最简单、最直接的方案。通过应用程序代理的方式效率会略低，因为下载的文件必须从 S3 传输到 Discourse 服务器，然后再传输到客户端。