Given 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>
...
这是一个用户脚本环境，因此我无权访问服务器配置。像这样：
- 我无法让服务器接受用户友好的文件名，例如
https://static.example.com/full/86fb269d190d2c85f6e0468ceca42a20 - 1337 - Hello World!.png.
- 我无法配置跨源资源共享。
www.example.com and static.example.com设计上由 CORS 墙隔开。
如何让Firefox和Chrome显示文件另存为带有建议文件名的对话框“1337 - 你好世界！.png”当用户单击“下载”链接时？
经过一些失败和谷歌搜索后，我了解到这些问题：
- Firefox 完全忽略了
download某些图像 MIME 类型的属性。
- Firefox 完全忽略了
download跨站点链接的属性。
- Chrome 完全忽略了
download跨站点链接的属性。
所有这些点都不能说明any对我来说，所有这些看起来都像是“让我们对功能进行随机的、无意义的限制”，但我必须接受它们，因为这是我的环境。
有没有办法解决这个问题？
背景：我正在为使用 MD5 哈希值作为文件名的图像板编写用户脚本。我希望使用用户友好的名称更容易保存。任何让我更接近这一点的事情都会有帮助。
我想我可以通过使用 blob 的对象 URL 和带有被黑客入侵的 CORS 标头的本地代理来绕过这些限制，但这种设置显然不合理。通过画布保存可以工作（在这种情况下图像也受到 CORS“保护”吗？），但对于给定的 JPEG 文件，它会强制双重有损压缩或有损到无损转换，这两种方法都不好。
所有现代浏览器都会忽略跨源 URL 锚标记中的下载属性。
参考 ：https://html.spec.whatwg.org/multipage/links.html#downloading-resources https://html.spec.whatwg.org/multipage/links.html#downloading-resources
根据规范制定者的说法，这代表了一个安全漏洞，因为用户可能会在浏览安全站点时被欺骗下载恶意文件，因为他们相信该文件也源自同一安全站点。
任何关于在 Firefox 浏览器中实现此功能的有趣对话都可以在这里找到：https://bugzilla.mozilla.org/show_bug.cgi?id=676619 https://bugzilla.mozilla.org/show_bug.cgi?id=676619
[阿塔里编辑]
引用自规格：
这可能很危险，因为例如，敌对服务器可能会试图让用户在不知情的情况下下载私人信息，然后通过欺骗用户认为数据来自敌对服务器，将其重新上传到敌对服务器。
因此，以某种方式通知用户所讨论的资源来自完全不同的源是符合用户利益的，并且为了防止混淆，来自潜在敌对接口来源的任何建议文件名都应该被忽略。
对神秘场景的澄清：
CORS 下载的更严重问题是恶意站点是否强制从合法站点下载文件以及如何访问其内容。假设我下载了用户 Gmail 收件箱页面并浏览其消息。
在这种情况下，邪恶站点将不得不欺骗用户下载文件并将其上传回服务器，因此假设我们有一个 gmail.com/inbox.html 实际上包含所有用户邮件消息，并且攻击者站点提供了优惠券文件的下载链接，应上传到另一个邪恶网站。据称，该优惠券将为购买新 iPad 提供 30% 的折扣。下载链接实际上会指向 gmail.com/inbox.html 并将其下载为“30off.coupon”，如果用户下载此文件并在不检查其内容的情况下上传，则邪恶网站将获得用户“优惠券”等等它的收件箱内容。
重要笔记：
-
Google 最初并没有通过 CORS 来限制下载属性，并且明确反对这一点。后来被迫调整 Chrome 的实现。
Google 反对为此使用 CORS。
-
提出了替代解决方案，向用户发出有关跨源下载的警告。他们被忽视了。
从另一个源下载时可以有通知或拒绝/允许机制（例如，像地理定位 API 一样）。或者在具有下载属性的跨源请求的情况下不发送 cookie。
-
一些开发人员确实认为限制太强，严重限制了该功能的使用，而且场景非常复杂，以至于执行此操作的用户可以轻松下载并运行可执行文件。他们的意见被忽视了。
反对允许跨源下载的理由是，[邪恶]网站（例如discountipads.com）的访问者可能会在不知情的情况下从包含其个人信息的网站（例如gmail.com）下载文件并保存使用误导性名称（例如“discount.coupon”）将其复制到磁盘上，然后进入另一个恶意页面，在那里他们手动上传刚刚下载的同一文件。在我看来，这是相当牵强的，任何愿意屈服于这种微不足道的诡计的人也许一开始就不属于网络。我的意思是来吧...单击此处下载我们的特别折扣优惠，然后通过我们的特殊表格重新上传！严重地？下载我们的特别优惠，然后通过电子邮件发送到此雅虎地址即可享受大折扣！那些陷入这些事情的人知道如何添加电子邮件附件吗？
我完全支持浏览器安全，但如果 Chromium 的好人对此没有问题，我不明白为什么 Firefox 必须完全消除它。至少我希望在 about:config 中看到一个首选项，为“高级”用户启用跨源@download（默认为 false）。更好的是一个确认框，类似于：“虽然此页面已加密，但您通过此表单提交的信息不会被加密”或：“此页面正在请求安装插件”或：“从网络下载的文件可能会损害您的计算机”甚至：“此页面的安全证书无效”...你知道我的意思吗？有多种方法可以提高用户的意识并告知他们这可能不安全。一次额外的点击和短暂（或长时间？）的延迟足以让他们评估风险。
随着网络的发展、CDN 使用的增长、高级网络应用程序的出现以及管理跨服务器托管文件的需求的增长，@download 等功能将变得更加重要。当像 Chrome 这样的浏览器完全支持它而 Firefox 不支持时，这对 Firefox 来说并不是一场胜利。
简而言之，我认为通过简单地忽略跨源场景中的属性来减轻 @download 的潜在邪恶用途是一个糟糕的想法不周的举动。我并不是说风险完全不存在，恰恰相反：我是说一个人每天在网上做很多有风险的事情……下载任何文件都是其中的高风险。为什么不通过深思熟虑的用户体验来解决这个问题呢？
总体而言，考虑到 CDN 的广泛使用并有意将用户生成的内容放在不同的域上，下载属性的主要用途是指定 blob 下载的文件名（URL.createObjectURL）等。它不能在很多配置中使用，当然在用户脚本中也不是很有用。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
