我在这里面临困境。我正在构建一个显示推文的Open Web App。如果这些推文中的任何一条包含图像的URL,我们会显示带有图像标记的图像。我想让用户选择将此图像保存到他的相册或使用共享网络活动共享它。
所有适用于图像的网络活动都希望blob能够正常运行。我们不能简单地将URL传递给它。我无法从远程图像构建blob,因为只要我尝试使用drawImage画布调用将该图像blit到画布中,我就会在画布上出现安全错误,因为图像不是来自与app相同的原点
此“安全”可防止所有类型的远程图像摆弄,例如将其保存到磁盘或使用Web活动。
我知道这是规范的一部分,但我并不真正理解其目的。毕竟它只是图像,如果我正在编写远程图像的保存脚本,我有可能知道我在做什么但是我又不是w3c小组的一部分决定了那个规范而且那些人更聪明比我更好,所以我可能会监督一些事情......
无论如何,让我们总结一下:“我如何从一个img标签出发,其源指向一个与Open Web App不同的远程位置,以及一个我可以用于web活动的blob?”
由于
答案 0 :(得分:3)
然后Share活动支持使用网址。 Boilerplate应用程序有一个example of this。如果您不介意您的应用具有特权(需要市场彻底审核),您可以尝试使用systemXHR。代码看起来类似于:
var xhr = new XMLHttpRequest({
mozSystem: true
});
xhr.open("GET", "url to image", true);
xhr.responseType = "blob";
xhr.onload = function () {
//sample activity - use any activity that requires blob
var activity = new MozActivity({
name: "open",
data: {
type: "image/png",
blob: this.response,
},
});
};
xhr.onerror = function () {
alert("Error with System XHR");
};
xhr.send();
答案 1 :(得分:2)
这不是"安全",这是安全。我理解你的挫败感,但你想做的事情本质上是不安全的,就像让网络应用程序访问本地文件一样。你发现它有用并不重要。那些坏人也可以。
加载图片绕过同一来源政策。这意味着任何Web应用程序都可以从浏览器用户当前登录的任何其他应用程序加载任何图像:电子邮件附件(包括PDF的再现),Facebook上的私人画廊,任何内容。这不会导致严重的攻击只是因为"访问"这种方式提供的图像非常少:您可以强制浏览器加载图像,但您无法将其读回或将其发送回服务器。对画布的无限制访问将破坏最后一道防线:攻击者可以加载您的秘密图像,将它们渲染到画布并回读数据。
它与iframe安全性的工作方式非常相似:由于任何Web应用程序都可以将任何其他应用程序加载到iframe中,因此无法从外部访问交叉原始iframe,您无法从中回读任何数据。