Question

我正在尝试用JavaScript编写RSS feed使用者，但不幸的是，大多数feed似乎并未在其响应中显式设置access-control-allow-origin头（即使据我了解，数据是公开的）消耗/抓取）。

我的问题是：有鉴于此，是否有办法在javascript中加载这样的数据（除了使用服务器端代理或将项目转换为浏览器插件外）

请求是简单的get请求。（因此，即使存在access-control-allow-origin标头，通常也不会发送OPTIONS请求）
Cookies /身份验证并不重要，因为提要是公开的。（因此，如果它是XMLHttpRequest，则withCredentials将为false）

例如像这样：

fetch('http://rss.slashdot.org/Slashdot/slashdotMain', {
  crossOrigin: false,
  xhrFields: {
    withCredentials: false
  }
})).then(function(response){
  console.log('Got a response!', response);
});

更新

我的问题的第二部分是：为什么不允许这样做？

例如：假设我出于任何原因导航到域wild-website.com。它将包含withCredentials: false的简单Ajax GET请求发送到my-bank.com。 my-bank.com处理此请求，但随后浏览器阻止了响应。

阻止对此获取请求的响应如何提高安全性？

是否在其他选项卡中登录my-bank.com都没有关系，因为没有按照withCredentials: false指令发送cookie或授权标头。经典的XSRF方案已经被阻止-此请求就像是互联网上的任何其他用户（包括恶意用户）已经加载了该资源一样。
如果URL中有一个身份验证令牌（例如JWT），那么恶意网站-恶意网站已经拥有了该令牌，以后可以将其存储起来供自己使用-阻止此特定响应不会对此进行更改。
它不会保护my-bank.com上的数据，因为它不会阻止请求，而只会阻止响应-如果它们具有REST风格的资源来响应该GET执行更新，那么我将拥有一个不好的时光。即：除非my-bank.com要求非简单的更新请求（POST或带有标头的请求，以便首先发送OPTIONS请求），否则不会阻止经典CSRF

那么，在这里阻止响应实际上有什么好处？

我想我正在寻找的答案是这样的：“如果还允许简单的withCredentials: false请求颠覆相同的原始策略，那么坏角色可以执行X。”

关于X是什么的任何想法？

有没有一种方法可以在服务器端未设置显式CORS标头的情况下加载跨源请求？

更新

0 个答案: