小编典典

从另一台服务器下载时,即使Access-Control-Allow-Origin设置为all(*),HTML5下载属性也不起作用

html

我有这样的下载链接:

<a href="foo.xls" download="bar.xls">Foobar</a>

在同一台服务器上下载文件时,此方法工作正常,但从另一台服务器(在本例中为Azure blob存储)下载文件时,即使HTTP响应返回以下标头,文件名仍为“
foo.xls”:

访问控制允许来源:*

这是设计使然,还是我可以将其他标头添加到HTTP响应中以使其正常工作?


阅读 343

收藏
2020-05-10

共1个答案

小编典典

是的,这是设计使CORS标头对download属性没有影响。只有两种支持该download属性的浏览器,即Firefox和Chrome,并且两种浏览器对跨域文件都有不同的策略。

实际上,65之前的 Chrome版本确实允许download跨域文件中的属性,而没有CORS标头,但Firefox却选择了不允许,理由是潜在的社交工程攻击。

MDN download在a标记的属性部分下记录了Firefox 20的此行为,此行为至今未更改。

在Firefox 20中,仅对具有相同来源的资源的链接授予此属性。

Bugzilla的这份报告讨论了安全问题以及使用CORS的可能性。

当用户单击这样的链接时,将提示用户是否要下载。用户似乎很容易犯错,以为是在下载原始网站上的内容,而不是从bank.com上下载的内容。

如果您对跨源安全性提出质疑,是否可以在考虑到相同来源和CORS(访问控制允许来源)的情况下实现它?这对于Web应用程序非常有用(使用JS创建Blob并让用户使用一些有意义的名称下载它)

Google反对为此使用CORS。

还有这个Bugzilla报告,该报告总结了其他bug报告中的决策。

另外,跨源下载在Google Chrome中也可以正常运行。

是的,我们认为他们这样做是在添加安全漏洞。

Bugzilla问题似乎并未排除download将来使用CORS进行跨域属性支持的可能性,但现在使用CORS标头对download属性没有任何作用。如果其他浏览器开始支持该属性,则可能会达成共识。

为了完整起见,当然有Content-Disposition标头,您可以使用该标头来强制从其他域下载,但这并不提供与download属性相同的功能。它确实具有更好的浏览器支持。

2020-05-10