了解基于 CORS 的 XMLHttpRequest (responseText)

2022-01-15 00:00:00 cors xmlhttprequest javascript

对于一个项目，我正在研究各种 HTML5 和 Javascript 元素以及它们周围的安全性，我现在正试图了解 CORS.

For a project I'm looking at various HTML5 and Javascript elements and security around them and I'm trying to get my head around CORS just now.

根据我的测试，如果我删除..

Based on my testing, if I remove..

<?php
 header("Access-Control-Allow-Origin: *"); 
 header('Access-Control-Allow-Methods: GET, POST, OPTIONS');
 ?>

..从尝试访问的页面中，我在 Chrome 的控制台日志中看到以下内容:

..from the page that is trying to be accessed I see the following in the console log on Chrome:

XMLHttpRequest cannot load http://www.bla.com/index.php. Origin http://bla2.com is not allowed by Access-Control-Allow-Origin.

我理解这是正确的，但是 Wireshark 在返回中显示 HTTP/1.1 200 OK，并且在数据中显示了所请求页面的来源.那么，是不是只有浏览器和 Javascript 才阻止 responseText 以任何实质性方式被使用，即使它实际上已经被传输了?

I understand this to be correct, however Wireshark shows HTTP/1.1 200 OK in the return and in the data shows the source of the page being requested. So is it just the browser and Javascript that is blocking responseText from being used in any substantial way even though it's actually transferred?

代码如下:

  function makeXMLRequest() {
  xmlhttp=new XMLHttpRequest();
xmlhttp.onreadystatechange = function() {
    if (xmlhttp.readyState==4) {
        alert(xmlhttp.responseText);
    }
}
xmlhttp.open("GET","http://www.bla.com/index.php",true);
xmlhttp.send();
}

提前致谢.

推荐答案

对于一个简单"的 HTTP 动词，比如 GET 或 POST，是的，整个页面被获取，然后浏览器决定 JavaScript 是使用内容还是不是.服务器不需要知道请求来自哪里；浏览器的工作是检查来自服务器的回复并确定是否允许 JS 看到内容.

For a "simple" HTTP verb like GET or POST, yes, the entire page is fetched, and then the browser decides whether JavaScript gets to use the contents or not. The server doesn't need to know where the requests comes from; it is the browser's job to inspect the reply from the server and determine if JS is permitted to see the contents.

对于像 PUT 或 DELETE 这样的非简单"HTTP 动词，浏览器使用 OPTIONS 请求发出预检请求".在这种情况下，浏览器首先检查是否支持域 和 动词，方法是检查 Access-Control-Allow-Origin 和 Access-Control- 允许方法，分别.(请参阅 上的处理不太简单的请求"HTML5 Rocks 的 CORS 页面 以获取更多信息.)预检响应还列出了允许的非简单标头，包含在 Access-Control-Allow-Headers 中.

For a "non-simple" HTTP verb like PUT or DELETE, the browser issues a "preflight request" using an OPTIONS request. In that case, the browser first checks to see if the domain and the verb are supported, by checking for Access-Control-Allow-Origin and Access-Control-Allow-Methods, respectively. (See the "Handling a Not-So-Simple Request" on the CORS page of HTML5 Rocks for more information.) The preflight response also lists permissible non-simple headers, included in Access-Control-Allow-Headers.

这是因为允许客户端向服务器发送 DELETE 请求可能非常糟糕，即使 JavaScript 永远无法看到跨域结果——再次记住，服务器通常没有任何义务进行验证请求来自合法域(尽管它可能使用请求中的 Origin 标头这样做).

This is because allowing a client to send a DELETE request to the server could be very bad, even if JavaScript never gets to see the cross-domain result -- again, remember that the server is generally not under any obligation to verify that the request is coming from a legitimate domain (although it may do so using the Origin header from the request).

相关文章