从另一台服务器下载时，下载HTML5属性不能正常工作，甚至当访问控制允许来源全部设置为（*） [英] HTML5 download attribute not working when downloading from another server, even when Access-Control-Allow-Origin is set to all (*)

问题描述

我有像这样一个下载链接：

 ＆LT; A HREF =foo.xls下载=bar.xls＆GT;＆Foobar的LT; / A＆GT;
 

在同一台服务器上下载文件时，但是从另一台服务器下载时（Azure的Blob存储在这种情况下）的文件名保持为foo.xls，尽管HTTP响应回来与下面的头也能正常工作

  

访问控制允许来源：*

在设计这还是有可能在另一头，我可以添加到HTTP响应得到这个工作？

解决方案

是的，这是由设计的CORS头文件中没有关于下载属性的影响。只有两种支持的浏览器下载属性，Firefox和Chrome，以及两种浏览器对跨源文件不同的策略。

浏览器实际上确实允许下载的跨域文件属性，没有CORS标头，但Firefox没有选择，理由是潜在的社会工程攻击。

MDN文件这种行为对Firefox 20在<一个href=\"https://developer.mozilla.org/en-US/docs/Web/HTML/Element/a#attr-download\"><$c$c>download属性的，既然没有改变 A 标记，行为部分。

  

在Firefox中20这个属性只荣幸与同源资源的链接。

本报告的Bugzilla讨论的安全关切，并使用CORS的可能性。

  

当用户点击这样的链接，用户将被提示，如果他们
  要下载。这似乎很容易为用户犯错误
  思考的东西原来的网站上正在
  下载，不是从bank.com。

  

    

这将有可能与同源和CORS来实现它
    （访问控制允许来源）记住，如果你质疑交叉起源
    安全？这是一个Web应用程序非常有用的功能（创建的Blob
    使用JS，让用户用一些有意义的名字下载）

  
  
  

谷歌反对使用CORS这一点。

还有本报告的Bugzilla ，它总结了其他bug报告他们的决定。

  

    

此外，跨起源下载是完全谷歌浏览器的工作。

  
  
  

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

Bugzilla的问题似乎并没有排除出采用CORS对跨域下载在未来属性支持的可能性，但现在使用CORS头呢这样做的下载属性什么。这是可能的，如果其他浏览器开始支持该属性，达成共识仍有可能达成。

为了完整起见，当然还有在内容处置头，您可以使用强制从其他域下载的，但这并不能提供同样的功能与下载属性。它有更好的浏览器支持虽然。

I have a download link like so:

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

This works fine when downloading a file on the same server, but when downloading from another server (Azure blob storage in this case) the filename stays as "foo.xls", even though the HTTP response comes back with the following header:

Access-Control-Allow-Origin: *

Is this by design or is there potentially another header I can to add to the HTTP response to get this to work?

解决方案

Yes, it is by design that the CORS headers have no affect on the download attribute. There are only two browsers that support the download attribute, Firefox and Chrome, and both browsers have a different policy on cross-origin files.

Chrome actually does allow the download attribute on cross-origin files, without CORS headers, but Firefox chose not to, citing potential social-engineering attacks.

MDN documents this behavior for Firefox 20 under the download attribute section for the a tag, behavior that has not changed since.

In Firefox 20 this attribute is only honored for links to resources with the same-origin.

This Bugzilla report discussed the security concerns and the possibility of using CORS.

When the user clicks such a link, the user will be prompted if they want to download. It seems very easy for the user to make the mistake of thinking that something on the original website is being downloaded, and not something from bank.com.

Would it be possible to implement it with same-origin and CORS (Access-Control-Allow-Origin) in mind if you are questioning cross origin security? This is very useful feature for web applications (create Blob using JS and let user download it with some meaningful name)

Google was opposed to using CORS for this.

There's also this Bugzilla report, which summarizes their decision from the other bug report.

Also, cross origin downloads are working perfectly in Google Chrome.

Yes, and we think they're adding security bugs by doing that.

The Bugzilla issues don't seem to rule-out the possibility of using CORS for cross-origin download attribute support in the future, but right now using CORS headers does not do anything for the download attribute. It's possible that if other browsers start supporting the attribute, a consensus may yet be reached.

For sake of completeness, there is of course the Content-Disposition header which you can use to force a download from the other domain, but this does not provide the same functionality as the download attribute. It does have better browser support though.

这篇关于从另一台服务器下载时，下载HTML5属性不能正常工作，甚至当访问控制允许来源全部设置为（*）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！