关于程序员:快速了解JavaScript的跨域

1次阅读

共计 6142 个字符，预计需要花费 16 分钟才能阅读完成。

浏览器有一个重要的安全策略，就是 同源策略，它用于限度不同源之间资源的交互。可能帮忙阻挡一些歹意的拜访，缩小可能被攻打的媒介。

上面看一下与该 URL http://chat.example.com/u1/arts1/101011.html 的源进行比照的示例。

URL	后果	起因
`http://chat.example.com/u2/arts1/101012.html`	同源	门路不同
`http://chat.example.com/u1/arts2/101013.html`	同源	门路不同
`https://chat.example.com/u2/arts2/101014.html`	失败	协定不同
`http://chat.example.com:88/u1/arts1/101015.html`	失败	端口不同(http:// 默认 80 端口)
`http://news.example.com/u3/arts4/101017.html`	失败	主机不同

因而，默认状况下应用 XMLHttpRequest 进行 Ajax 通信，不能拜访除它本人以外的域、协定和端口。但浏览器也须要有非法跨源拜访的能力。

图片探测是利用 <img> 标签实现跨域通信的最早的一种技术。任何页面都能够跨域加载图片而不用放心限度，因而这也是在线广告跟踪的次要形式。能够动态创建图片，而后通过它们的 onload 和 onerror 事件处理程序得悉何时收到响应。

这种动态创建图片的技术常常用于 图片探测（image pings）。图片探测是与服务器之间简略、跨域、单向的通信。数据通过查问字符串发送，响应能够随时设置，不过个别是位图图片或值为 204 的状态码。浏览器通过图片探测拿不到任何数据，但能够通过监听 onload 和 onerror 事件晓得什么时候能接管到响应。上面看一个例子：

let img = new Image();
img.onload = img.onerror = function() {console.log("已实现!");
};
img.src = "http://www.example.com/test?name=Manoa";

这个例子创立了一个新的 Image 实例，而后给 onload 和 onerror 事件增加同一个函数。这样可确保申请实现时，无论成否都会收到告诉。设置完 src 属性之后申请就会开始，这个例子向服务器发送了一个 name 值。

图片探测频繁用于跟踪用户在页面上的点击操作或动态显示广告。当然，图片探测的毛病是只能发送 GET 申请和无奈获取服务器响应的内容。这也是只能利用探测实现浏览器与服务器单向通信的起因。

JSONP（JSON with padding）是 JSON 的一种变体。用于解决浏览器的跨域问题。须要动态创建 <script> 元素并为 src 属性指定跨域 URL，并将一个回调函数指定在 URL 前面。这样可能不受限制地从其它域加载资源。上面是一个 JSONP 的 URL：

http://example.com/json/?callback=handleResponse

而想要发送这样的 HTTP 申请，咱们就须要实现如下脚本：

function handleResponse(response) {
    console.log(`
        You're at IP address ${response.ip}, which is in
${response.city}, ${response.region_name}`);
}
let script = document.createElement("script");
script.src = "http://example.com/json/?callback=handleResponse";
document.body.insertBefore(script, document.body.firstChild);

JSONP 因为其简略易用，在开发者中十分风行。相比图片探测，应用 JSONP 能够间接拜访响应，实现浏览器与服务器的双向通信。不过 JSONP 也有一些毛病。

首先，JSONP 是从不同的域拉取可执行代码。如果这个域并不可信，则可能在响应中退出歹意内容。此时除了齐全删除 JSONP 没有其它方法。在应用不受控的 Web 服务时，肯定要保障是能够信赖的。

第二个毛病是不好确定 JSONP 申请是否失败。尽管 HTML5 规定了 <script> 元素的 onerror 事件处理程序，但还没有被任何浏览器实现。为此，开发者常常应用计数器来决定是否放弃期待响应。这种形式并不精确，毕竟不同用户的网络连接速度和带宽是不一样的。

CORS 呈现之前，实现跨源 Ajax 通信是有点麻烦的。开发者须要依赖可能执行跨源申请的 DOM 个性，在不应用 XMLHttpRequest 对象状况下发送某种类型的申请。尽管 CORS 目前曾经失去广泛支持，但这些技术依然没有过期，因为它们不须要批改服务器。

在 CORS 呈现之前，实现跨源 Ajax 通信有点麻烦。开发者须要依赖可能执行跨源申请的 DOM 个性，在不应用 XMLHttpRequest 的状况下发送某种类型的申请。而 CORS 跨域呈现之后，就比拟不便了，但也不是说下面介绍的技术曾经过期，因为它们不须要批改服务的缘故，还是有应用的场景。上面介绍下 CORS。

跨源资源共享（CORS，Cross-Origin Resource Sharing）是一种基于 HTTP 头的机制，该机制通过容许服务器自定义 HTTP 头部容许浏览器与服务器实现跨源通信。

出于安全性，浏览器限度脚本内发动的跨源 HTTP 申请。例如，XMLHttpRequest 和 Fetch API 遵循同源策略。这意味着应用这些 API 的 Web 应用程序只能从加载应用程序的同一个域申请 HTTP 资源，而 CORS 是 HTTP 的一部分，它容许服务端来指定哪些主机能够从这个服务端加载资源，因而要响应报文中要蕴含 CORS 响应头。

不会触发 CORS 预检申请的申请称为“简略申请”。“简略申请”的申请形式是 GET、HEAD 或 POST三种之一，首部字段次要是以下字段汇合：

Accept
Accept-Language
Content-Language
Content-Type：只限 text/plain、multipart/form-data 和 application/x-www-form-urlencoded 三者之一。

没有自定义头部，申请在发送时会有一个额定的 Origin 头部，其蕴含发送申请的页面的源，以便服务器的确是否为其提供响应。上面是 Origin 头部的一个示例：

Origin: http://www.example.com

如果服务器决定响应申请，那么应该发送 Access-Control-Allow-Origin 头部，蕴含雷同的源；或者如果资源是公开的，那么就蕴含 "*"。比方：

Access-Control-Allow-Origin: http://www.example.com

如果没有这个头部，或者有但源不匹配，则表明不会响应浏览器申请。否则，服务器就会解决这个申请。留神，无论申请还是响应都不会蕴含 cookie 信息。

古代浏览器通过 XMLHttpRequest 对象原生反对 CORS。在尝试拜访不同源的资源时，这个行为会被主动触发。要向不同域的源发送申请，能够应用规范 XMLHttpRequest 对象并给 open() 办法传入一个相对 URL，比方：

let xhr = new XMLHttpRequest();
xhr.onreadystatechange = function() {if (xhr.readyState == 4) {if ((xhr.status >= 200 && xhr.status < 300) || xhr.status == 304) {console.log(xhr.responseText);
        } else {console.log("申请失败:" + xhr.status);
        }
    }
};
xhr.open("get", "http://www.examplecom/page/", true);
xhr.send(null);

跨域 XMLHttpRequest 对象容许拜访 status 和 statusText 属性，也容许同步申请。出于平安思考，跨域 XMLHttpRequest 对象也施加了一些额定限度。

不能应用 setRequestHeader() 设置自定义头部。
不能发送和接管 cookie。
getAllResponseHeaders() 办法始终返回空字符串。

因为无论同域还是跨域申请都应用同一个接口，所以最好在拜访本地资源时应用绝对 URL，在拜访近程资源时应用相对 URL。这样能够更明确地区分应用场景，同时避免出现拜访本地资源时呈现头部或 cookie 信息拜访受限的问题。

CORS 通过一种预检申请（preflighted request）的服务器验证机制，容许应用自定义头部、除 GET 和 POST 之外的办法，以及不同申请体内容类型。在要发送波及上述某种高级选项的申请时，会先向服务器发送一个“预检”申请。这个申请应用 OPTIONS 办法发送并蕴含以下头部。

Origin：与简略申请雷同。
Access-Control-Request-Method：申请心愿应用的办法。
Acces-Control-Request-Headers：（可选）要应用的逗号分隔的自定义头部列表。

上面是一个假如的 POST 申请，蕴含自定义的 NCZ 头部：

Origin: http://www.example.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: NCZ

在这个申请发送后，服务器能够确定是否容许这种类型的申请。服务器会通过在响应中发送如下头部与浏览器沟通这些信息。

Access-Control-Allow-Origin：与简略申请雷同。
Access-Control-Allow-Methods：容许的办法（逗号分隔的列表）。
Access-Control-Allow-Headers：服务器容许的头部（逗号分隔的列表）。
Access-Control-Max-Age：缓存预检申请的秒数。

例如：

Access-Control-Allow-Origin: http://www.example.com
Access-Control-Allow-Methods: POST, GET
Access-Control-Allow-Headers: NCZ
Access-Control-Max-Age: 1728000

预检申请返回后，后果会按响应指定的工夫缓存一段时间。换句话说，只有第一次发送这种类型的申请时才会多发送一次额定的 HTTP 申请。“预检申请”的应用，能够防止跨域申请对服务器的用户数据产生未预期的影响。

默认状况下，跨源申请不提供凭据（cookie、HTTP 认证和客户端 SSL 证书）。能够通过将 withCredentials 属性设置为 true 来表明申请会发送凭据。如果服务器容许带凭据的申请，那么能够在响应中蕴含如下 HTTP 头部：

Access-Control-Allow-Credentials: true

如果发送了凭据申请而服务器返回的响应中没有这个头部，则浏览器不会把响应交给 JavaScript（responseText 是空字符串，status 是 0，onerror() 被调用）。留神，服务器也能够在预检申请的响应中发送这个 HTTP 头部，以表明这个源容许发送凭据申请。

上面列出标准所定义的响应首部字段。

Access-Control-Expose-Headers

容许拜访该资源的外域 URI。<origin> 参数的值是容许的外域。而设置成通配符 * 则是服务器容许来自所有域的申请。

Access-Control-Allow-Origin: <origin> | *

Access-Control-Expose-Headers

服务器把容许浏览器拜访的头放入白名单，浏览器中的 XMLHttpRequest 就能够通过 getResponseHeader 拜访响应头的 X-My-Custom-Header 和 X-Another-Custom-Header。

Access-Control-Expose-Headers: X-My-Custom-Header, X-Another-Custom-Header

Access-Control-Max-Age

指定了预检申请的后果可能被缓存的秒数。

Access-Control-Max-Age: <delta-seconds>

Access-Control-Allow-Credentials

指定了当浏览器的 credentials 设置为 true 时是否容许浏览器读取 response 的内容。当用在对预检申请的响应中时，它指定了理论的申请是否能够应用 credentials。

Access-Control-Allow-Credentials: true

留神：简略 GET 申请不会被预检；如果对此类申请的响应中不蕴含该字段，响应将被疏忽，并且浏览器也不会将相应内容返回给网页。

Access-Control-Allow-Methods

首部字段用于预检申请的响应。指明了理论申请所容许应用的 HTTP 办法。

Access-Control-Allow-Methods: <method>[, <method>]*

Access-Control-Allow-Headers

首部字段用于预检申请的响应。其指明了理论申请中容许携带的首部字段。

Access-Control-Allow-Headers: <field-name>[, <field-name>]*

上面列出标准所定义的可用于发动跨源申请的首部字段。留神：这些首部字段毋庸手动设置。应用 XMLHttpRequest 时会主动设置。

Origin

表明预检申请或理论申请的源（协定、域名和端口）。

Origin: <origin>

origin 参数的值为源站 URI。它不蕴含任何门路信息，只是服务器名称。留神：在所有访问控制申请（Access control request）中，Origin 首部字段总是被发送。

Access-Control-Request-Method

用于预检申请。其作用是，将理论申请所应用的 HTTP 办法通知服务器。

Access-Control-Request-Method: <method>

Access-Control-Request-Headers

用于预检申请。其作用是，将理论申请所携带的首部字段通知服务器。

Access-Control-Request-Headers: <field-name>[, <field-name>]*

XMLHttpRequest 不容许拜访其它域名、协定和端口的资源，拜访的话会导致平安谬误，这是因为浏览器的同源策略所造成的。而想要跨源拜访，就须要应用跨源资源共享计划，XMLHttpRequest原生反对 CORS。图片探测和 JSONP 是另两种跨域通信技术，但与 CORS 相比，不是很牢靠。

更多内容请关注公众号「海人为记」

正文完