javascript - 使Firefox和Chrome以特定名称下载图像

Question

给定 https://www.example.com/image-list:

...
<a href="/image/1337">
  <img src="//static.example.com/thumbnails/86fb269d190d2c85f6e0468ceca42a20.png"/>
</a>
<a href="//static.example.com/full/86fb269d190d2c85f6e0468ceca42a20.png"
   download="1337 - Hello world!.png">
  Download
</a>
...

这是一个用户脚本环境，所以我无权访问服务器配置。因此:

1. 我无法让服务器接受用户友好的文件名，例如 https://static.example.com/full/86fb269d190d2c85f6e0468ceca42a20 - 1337 - Hello World!.png。
2. 我无法配置跨源资源共享。 www.example.com 和 static.example.com 在设计上由 CORS 墙分隔。

如何让 Firefox 和 Chrome 在用户点击“下载”链接？

经过一些失败和谷歌搜索，我发现了这些问题:

1. Firefox 完全忽略某些图像 MIME 类型上存在的 download 属性。
2. Firefox 完全忽略跨站点链接上 download 属性的存在。
3. Chrome 完全忽略跨站点链接上 download 属性的值。

所有这些观点对我来说没有任何意义，看起来都像是“让我们对功能施加随机的无意义限制”，但我必须接受它们，因为这是我的环境。

有什么办法可以解决这个问题吗？

---

背景:我正在为使用 MD5 哈希值作为文件名的图像板编写用户脚本。我想让使用用户友好的名称保存起来更容易。任何让我更接近这一点的事情都会有所帮助。

我想我可以通过使用 blob 的对象 URL 和带有被黑 CORS header 的本地代理来绕过这些限制，但这种设置显然超出了合理范围。通过 Canvas 保存可能有效(在这种情况下，图像是否也受 CORS“保护”？)，但它会强制进行双重有损压缩或有损到无损转换，给定 JPEG 文件，这两者都不好。

Answer 1

所有现代浏览器都会忽略跨源 URL 的 anchor 标记中的下载属性。

引用:https://html.spec.whatwg.org/multipage/links.html#downloading-resources

根据规范制定者的说法，这代表了一个安全漏洞，因为用户可能会在浏览安全站点时被诱骗下载恶意文件，并认为该文件也来自同一安全站点。

有关在 firefox 浏览器中实现此功能的任何有趣对话都可以在这里找到:https://bugzilla.mozilla.org/show_bug.cgi?id=676619

---

[ Athari 编辑]

规范引用:

This could be dangerous, because, for instance, a hostile server could be trying to get a user to unknowingly download private information and then re-upload it to the hostile server, by tricking the user into thinking the data is from the hostile server.

Thus, it is in the user's interests that the user be somehow notified that the resource in question comes from quite a different source, and to prevent confusion, any suggested filename from the potentially hostile interface origin should be ignored.

对神秘场景的澄清:

the more serious issue with CORS downloads is if a malicious site forces a download of a file form a legitimate site and some how gets access to its content. so lets say I download the user gmail inbox page and explore its messages.

in this case an evil site will have to fool the user into downloading the file and uploading it back to the server, so lets say we have a gmail.com/inbox.html actually contains all the user mail messages and the attacker sites offers a download link for a coupon file, that should be uploaded to another evil site. the coupon will supposedly offer a 30% discount on a new Ipad. the download link will actually point to gmail.com/inbox.html and will download it as "30off.coupon", the if the user will download this file and upload it without checking it's content the evil site will get the user "coupon" and so its inbox content.

重要提示:

1. Google 最初并没有通过 CORS 限制下载属性，并且明确反对这一点。后来被迫调整 Chrome 实现。

   Google was opposed to using CORS for this.

2. 提出了替代解决方案，向用户发出有关跨域下载的警告。他们被忽略了。

   Well there can be notification or deny/allow mechanism when downloading from another origin (e.g. like in case of geolocation API). Or not to send cookies in case of cross origin request with download attribute.

3. 确实有一些开发人员认为限制太强，严重限制了该功能的使用，而且场景非常复杂，以至于执行此操作的用户很容易下载并运行可执行文件。他们的意见被忽视了。

   The case against allowing cross-origin downloads is centered around the premise that visitors of an [evil] site (eg, discountipads.com) could unknowingly download a file from a site containing their own personal information (eg, gmail.com) and save it to their disk using a misleading name (eg, "discount.coupon") AND THEN proceed to another malicious page where they manually upload that same file they just downloaded. This is quite far-fetched in my opinion, and anyone who would succumb to such trivial trickery perhaps does not belong online in the first place. I mean c'mon...Click here to download our special discount offer and then re-upload it through our special form! Seriously? Download our special offer and then email it to this Yahoo address for a big discount! Do the people who fall for these things even know how to do email attachments?

   I'm all for browser security, but if the good people of Chromium have no problem with this I don't see why Firefox has to completely banish it. At the very least I'd like to see a preference in about:config to enable cross-origin @download for "advanced" users (default it to false). Even better would be a confirmation box similar to: "Although this page is encrypted, the information you submit through this form won't be" or: "This page is requesting to install addons" or: "Files downloaded from the web may harm your computer" or even: "The security certificate of this page is invalid" ...y'know what I mean? There are myriad ways to heighten the user's awareness and inform them this might not be safe. One extra click and a short (or long?) delay is enough to let them assess the risk.

   As the web grows, and the use of CDNs grows, and the presence of advanced web-apps grows, and the need to manage files hosted across servers grows, features like @download will become more important. And when a browser like Chrome supports it fully whereas Firefox does not, this is not a win for Firefox.

   In short, I think that mitigating the potential evil uses of @download by simply ignoring the attribute in cross-origin scenarios is a woefully ill-thought move. I'm not saying the risk is entirely non-existent, quite the contrary: I am saying there are plenty of risky things one does online in the course of his day...downloading ANY file is high among them. Why not work around that issue with a well-thought user experience?

总的来说，考虑到 CDN 的广泛使用以及有意将用户生成的内容放在不同的域中，下载属性的主要用途是为 blob 下载指定文件名 (URL.createObjectURL) 和类似。它不能用于很多配置，当然在用户脚本中也不是很有用。