私の研究ではクロスドメイン関連のコンテンツをよく目にしますが、この記事ではスター領域のクロスドメインのソリューションを提供します。
クロスドメイン ソリューション
1. jsonp によるクロスドメイン
2. document.domain + iframe クロスドメイン
4. window.name + iframe クロスドメイン
5.ドメイン
6. クロスドメイン リソース共有 (CORS)
7、nginx プロキシ クロスドメイン
8、nodejs ミドルウェア プロキシ クロスドメイン
9、jsonp を介したクロスドメイン
1。 Web サーバーの負荷を軽減するために、js を配置します。css や img などの静的リソースは、独立したドメイン名を持つ別のサーバーに分離されます。静的リソースは、HTML ページ内の対応するタグを介して別のドメイン名から読み込まれ、許可されます。この原理に基づいて、スクリプトを動的に作成し、パラメータを含む URL をリクエストして、クロスドメイン通信を実現できます。
1.) ネイティブ実装:
<script>
var script = document.createElement('script');
script.type = 'text/javascript'; // 传参并指定回调执行函数为onBack script.src = 'http://www.domain2.com:8080/login?user=admin&callback=onBack'; document.head.appendChild(script); // 回调执行函数 function onBack(res) {
alert(JSON.stringify(res));
} </script>onBack({"status": true, "user": "admin"})
2.）jquery ajax：
$.ajax({ url: 'http://www.domain2.com:8080/login', type: 'get', dataType: 'jsonp', // 请求方式为jsonp jsonpCallback: "onBack", // 自定义回调函数名 data: {}});3.）vue.js：
this.$http.jsonp('http://www.domain2.com:8080/login', { params: {}, jsonp: 'onBack'}).then((res) => { console.log(res); })バックエンドのnode.js コード例:
var querystring = require('querystring');var http = require('http');var server = http.createServer();
server.on('request', function(req, res) {var params = qs.parse(req.url.split('?')[1]);
var fn = params.callback; // jsonp返回设置 res.writeHead(200, { 'Content-Type': 'text/javascript' });
res.write(fn + '(' + JSON.stringify(params) + ')');
res.end();});
server.listen('8080');console.log('Server is running at port 8080...');jsonp 欠点: 1 種類の get リクエストしか実装できません。 。
2. document.domain + iframe クロスドメイン このソリューションは、メイン ドメインは同じだがサブドメインが異なる、クロスドメイン アプリケーションのシナリオに限定されます。
実装原則: どちらのページも、js を通じて document.domain を基本的なメイン ドメインとして強制的に設定することで、同じドメインを実現します。
1.) 親ウィンドウ: (http://www.domain.com/a.html))
<iframe id="iframe" src="http://child.domain.com/b.html"></iframe><script> document.domain = 'domain.com'; var user = 'admin';</script>
<script> document.domain = 'domain.com'; // 获取父窗口中变量 alert('get js data from parent ---> ' + window.parent.user);</script>
3. location.hash + iframe クロスドメイン実装原則: a はドメインを越えて b と通信したいと考えており、これは中間ページ c を通じて実現されます。 3 ページの場合、異なるドメイン間の値の転送には iframe の location.hash が使用され、同じドメイン間の通信にはダイレクト JS アクセスが使用されます。
具体的な実装: ドメイン A: a.html -> ドメイン B: b.html -> ドメイン A: c.html。異なるドメイン a と b はハッシュ値を通じてのみ通信できます。異なるドメイン間の通信は一方向のみですが、c と a は同じドメイン内にあるため、c はparent.parent を通じて a ページ上のすべてのオブジェクトにアクセスできます。1.) a.html: ([http://www.domain1.com/a.html)]
<iframe id="iframe" src="http://www.domain2.com/b.html" style="display:none;"></iframe><script> var iframe = document.getElementById('iframe');
// 向b.html传hash值 setTimeout(function() {
iframe.src = iframe.src + '#user=admin';
}, 1000);
< ; iframe id="iframe" src="http://www.domain1.com/c.html" style="display:none;"><script> var iframe = document.getElementById( ' iframe'); </p>// a.html からのハッシュ値を監視し、それを c.htmlwindow.onhashchange = function () {<p>iframe.src = iframe.src + location.hash </p>};</script> ;
3.) c.html: (http://www.domain1.com/c.html))
<script> // b.html</p>からハッシュ値を監視します window.onhashchange = function ( ) { // 次に、同じドメイン内の a.html の js コールバックを操作すると、結果が window.parent.parent.onCallback('hello: ' + location.hash.replace('#user=', ' ')) ; };</script>
4. window.name + iframe クロスドメイン
window.name 属性の一意性: 名前の値は、異なるページ (または異なるドメイン名) を変更した後でも存在します。ロードされており、非常に長い名前の値 (2MB) をサポートできます。
1.) a.html: (http://www.domain1.com/a.html))
var proxy = function(url, callback) { var state = 0;
var iframe = document.createElement('iframe'); // 加载跨域页面 iframe.src = url;// onload事件会触发2次，第1次加载跨域页，并留存数据于window.name iframe.onload = function() { if (state === 1) { // 第2次onload(同域proxy页)成功后，读取同域window.name中数据 callback(iframe.contentWindow.name);
destoryFrame();
}
else if (state === 0) {
// 第1次onload(跨域页)成功后，切换到同域代理页面 iframe.contentWindow.location = 'http://www.domain1.com/proxy.html'; state = 1;
}
};
document.body.appendChild(iframe);// データを取得した後、iframe を破棄し、メモリを解放します。これにより、安全性も確保されます (フレーム化されません)。他のドメイン) js アクセス) function destoryFrame() {
iframe.contentWindow.document.write(''); iframe.contentWindow.close(); document.body.removeChild(iframe); }
alert(data) ;
});
2.) proxy.html: (http://www.domain1.com/proxy....) 中間プロキシ ページは a.html と同じドメインにあります。コンテンツは空にすることもできます。
3.) b.html: (http://www.domain2.com/b.html))
<script> window.name = 'This is domain2 data!';</script>
5. postMessage クロスドメイン
postMessage は HTML5 XMLHttpRequest レベル 2 の API であり、ドメイン間で操作できる数少ないウィンドウ属性の 1 つであり、次の問題を解決するために使用できます: a.) ページと新しいページ。 b.) 複数のウィンドウ間のメッセージ転送 c.) ページおよびネストされた iframe メッセージ転送 d.) 上記 3 つのシナリオにおけるクロスドメイン データ転送
1.) a.html: (http://www.domain1.com/a.html))
<iframe id="iframe" src="http://www.domain2.com/b.html" style="display:none;"></iframe><script> var iframe = document.getElementById('iframe');
iframe.onload = function() { var data = { name: 'aym' };// 向domain2传送跨域数据 iframe.contentWindow.postMessage(JSON.stringify(data), 'http://www.domain2.com'); }; // 接受domain2返回数据 window.addEventListener('message', function(e) {
alert('data from domain2 ---> ' + e.data);
}, false);</script><script> // 接收domain1的数据 window.addEventListener('message', function(e) {
alert('data from domain1 ---> ' + e.data); var data = JSON.parse(e.data);
if (data) { data.number = 16;
// 处理后再发回domain1
window.parent.postMessage(JSON.stringify(data), 'http://www.domain1.com'); }
},
false);</script>六、 跨域资源共享（CORS）
普通跨域请求：只服务端设置Access-Control-Allow-Origin即可，前端无须设置，若要带cookie请求：前后端都需要设置。
需注意的是：由于同源策略的限制，所读取的cookie为跨域请求接口所在域的cookie，而非当前页。如果想实现当前页cookie的写入，可参考下文：七、nginx反向代理中设置proxy_cookie_domain 和 八、NodeJs中间件代理中cookieDomainRewrite参数的设置。
目前，所有浏览器都支持该功能(IE8+：IE8/9需要使用XDomainRequest对象来支持CORS）)，CORS也已经成为主流的跨域解决方案。
1、 前端设置：
1.）原生ajax
// 前端设置是否带cookiexhr.withCredentials = true;
示例代码：
var xhr = new XMLHttpRequest();// IE8/9需用window.XDomainRequest兼容// 前端设置是否带cookiexhr.withCredentials = true;xhr.open('post', 'http://www.domain2.com:8080/login', true);
xhr.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded');
xhr.send('user=admin');
xhr.onreadystatechange = function() { if (xhr.readyState == 4 && xhr.status == 200) {
alert(xhr.responseText);
}
};2.）jQuery ajax
$.ajax({
...
xhrFields: {
withCredentials: true // 前端设置是否带cookie },
crossDomain: true, // 会让请求头中包含跨域的额外信息，但不会含cookie ...
});
3.）vue框架在vue-resource封装的ajax组件中加入以下代码：
Vue.http.options.credentials = true
2、 服务端设置：
若后端设置成功，前端浏览器控制台则不会出现跨域报错信息，反之，说明没设成功。
1.）Java后台：
/* * 导入包：import javax.servlet.http.HttpServletResponse; * 接口参数中定义：HttpServletResponse response */response.setHeader("Access-Control-Allow-Origin", "http://www.domain1.com"); // 若有端口需写全（协议+域名+端口）response.setHeader("Access-Control-Allow-Credentials", "true");
2.）Nodejs后台示例：
var http = require('http');var server = http.createServer();var qs = require('querystring');
server.on('request', function(req, res) {
var postData = '';
// 数据块接收中 req.addListener('data', function(chunk) {
postData += chunk; });
// 数据接收完毕 req.addListener('end', function() {
postData = qs.parse(postData); // 跨域后台设置 res.writeHead(200, { 'Access-Control-Allow-Credentials': 'true', // 后端允许发送Cookie 'Access-Control-Allow-Origin': 'http://www.domain1.com', // 允许访问的域（协议+域名+端口） 'Set-Cookie': 'l=a123456;Path=/;
Domain=www.domain2.com;HttpOnly' // HttpOnly:脚本无法读取cookie }); res.write(JSON.stringify(postData)); res.end();
});
});
server.listen('8080');
console.log('Server is running at port 8080...');七、 nginx代理跨域
1、 nginx配置解决iconfont跨域
浏览器跨域访问js、css、img等常规静态资源被同源策略许可，但iconfont字体文件(eot|otf|ttf|woff|svg)例外，此时可在nginx的静态资源服务器中加入以下配置。
location / {
add_header Access-Control-Allow-Origin *;
}
2、 nginx反向代理接口跨域
跨域原理： 同源策略是浏览器的安全策略，不是HTTP协议的一部分。服务器端调用HTTP接口只是使用HTTP协议，不会执行JS脚本，不需要同源策略，也就不存在跨越问题。
实现思路：通过nginx配置一个代理服务器（域名与domain1相同，端口不同）做跳板机，反向代理访问domain2接口，并且可以顺便修改cookie中domain信息，方便当前域cookie写入，实现跨域登录。
nginx具体配置：
#proxy服务器server {
listen 81;
server_name www.domain1.com;
location / {
proxy_pass http://www.domain2.com:8080; #反向代理 proxy_cookie_domain www.domain2.com www.domain1.com; #修改cookie里域名
index index.html index.htm;
# 当用webpack-dev-server等中间件代理接口访问nignx时，此时无浏览器参与，故没有同源限制，下面的跨域配置可不启用 add_header Access-Control-Allow-Origin http://www.domain1.com; #当前端只跨域不带cookie时，可为*
add_header Access-Control-Allow-Credentials true;
}
}1.) 前端代码示例：
var xhr = new XMLHttpRequest();// 前端开关：浏览器是否读写cookiexhr.withCredentials = true;// 访问nginx中的代理服务器xhr.open('get', 'http://www.domain1.com:81/?user=admin', true);
xhr.send();
2.) Nodejs后台示例：
var http = require('http');var server = http.createServer();var qs = require('querystring');
server.on('request', function(req, res) {
var params = qs.parse(req.url.substring(2)); // 向前台写cookie res.writeHead(200, {
'Set-Cookie': 'l=a123456;Path=/;Domain=www.domain2.com;HttpOnly' // HttpOnly:脚本无法读取 });
res.write(JSON.stringify(params)); res.end();
});
server.listen('8080');console.log('Server is running at port 8080...');八、 Nodejs中间件代理跨域
node中间件实现跨域代理，原理大致与nginx相同，都是通过启一个代理服务器，实现数据的转发，也可以通过设置cookieDomainRewrite参数修改响应头中cookie中域名，实现当前域的cookie写入，方便接口登录认证。
1、 非vue框架的跨域（2次跨域）
利用node + express + http-proxy-middleware搭建一个proxy服务器。
1.）前端代码示例：
var xhr = new XMLHttpRequest();// 前端开关：浏览器是否读写cookiexhr.withCredentials = true;// 访问http-proxy-middleware代理服务器xhr.open('get', 'http://www.domain1.com:3000/login?user=admin', true); xhr.send();
2.）中间件服务器：
var express = require('express');var proxy = require('http-proxy-middleware');var app = express();
app.use('/', proxy({
// 代理跨域目标接口 target: 'http://www.domain2.com:8080',
changeOrigin: true,
// 修改响应头信息，实现跨域并允许带cookie onProxyRes: function(proxyRes, req, res) {
res.header('Access-Control-Allow-Origin', 'http://www.domain1.com'); res.header('Access-Control-Allow-Credentials', 'true'); },
// 修改响应信息中的cookie域名 cookieDomainRewrite: 'www.domain1.com' // 可以为false，表示不修改}));
app.listen(3000);console.log('Proxy server is listen at port 3000...');3.）Nodejs后台同（六：nginx）
2、 vue框架的跨域（1次跨域）
利用node + webpack + webpack-dev-server代理接口跨域。在开发环境下，由于vue渲染服务和接口代理服务都是webpack-dev-server同一个，所以页面与代理接口之间不再跨域，无须设置headers跨域信息了。
webpack.config.js部分配置：
module.exports = {
entry: {}, module: {},
...
devServer: {
historyApiFallback: true,
proxy: [{
context: '/login',
target: 'http://www.domain2.com:8080', // 代理跨域目标接口 changeOrigin: true,
cookieDomainRewrite: 'www.domain1.com' // 可以为false，表示不修改
}],
noInfo: true }}九、 WebSocket协议跨域
WebSocket protocol是HTML5一种新的协议。它实现了浏览器与服务器全双工通信，同时允许跨域通讯，是server push技术的一种很好的实现。原生WebSocket API使用起来不太方便，我们使用Socket.io，它很好地封装了webSocket接口，提供了更简单、灵活的接口，也对不支持webSocket的浏览器提供了向下兼容。
1.）前端代码：
<p>user input：<input type="text"></p><script src="./socket.io.js"></script><script>var socket = io('http://www.domain2.com:8080');// 连接成功处理socket.on('connect', function() { // 监听服务端消息
socket.on('message', function(msg) {
console.log('data from server: ---> ' + msg);
}); // 监听服务端关闭 socket.on('disconnect', function() {
console.log('Server socket has closed.');
});
});document.getElementsByTagName('input')[0].onblur = function() {
socket.send(this.value);};</script>2.）Nodejs socket后台：
var http = require('http');var socket = require('socket.io');// 启http服务var server = http.createServer(function(req, res) {
res.writeHead(200, {
'Content-type': 'text/html'
});
res.end();
});
server.listen('8080');console.log('Server is running at port 8080...');// 监听socket连接socket.listen(server).on('connection', function(client) {
// 接收信息 client.on('message', function(msg) {
client.send('hello：' + msg);
console.log('data from client: ---> ' + msg);
});
// 断开处理 client.on('disconnect', function() {
console.log('Client socket has closed.');
});
});附：
同源策略限制从一个源加载的文档或脚本如何与来自另一个源的资源进行交互。这是一个用于隔离潜在恶意文件的关键的安全机制。但是有时候跨域请求资源是合理的需求，本文尝试从多篇文章中汇总至今存在的所有跨域请求解决方案。
跨域请求
首先需要了解的是同源和跨源的概念。对于相同源，其定义为：如果协议、端口（如果指定了一个）和主机对于两个页面是相同的，则两个页面具有相同的源。只要三者之一任意一点有不同，那么就为不同源。当一个资源从与该资源本身所在的服务器的域或端口不同的域或不同的端口请求一个资源时，资源会发起一个跨域 HTTP 请求。而有关跨域请求受到限制的原因可以参考如下 MDN 文档片段：
跨域不一定是浏览器限制了发起跨站请求，而也可能是跨站请求可以正常发起，但是返回结果被浏览器拦截了。最好的例子是 CSRF 跨站攻击原理，请求是发送到了后端服务器无论是否跨域！注意：有些浏览器不允许从 HTTPS 的域跨域访问 HTTP，比如 Chrome 和 Firefox，这些浏览器在请求还未发出的时候就会拦截请求，这是一个特例。
解决方法汇总
以下我们由简及深介绍各种存在的跨域请求解决方案，包括 document.domain, location.hash, window.name, window.postMessage, JSONP, WebSocket, CORS
。
document.domain document.domain 的作用是用来获取/设置当前文档的原始域部分，例如： // 对于文档 www.example.xxx/good.htmldocument.domain="www.example.xxx"// 对于URI http://developer.mozilla.org/en/docs/DOM document.domain="developer.mozilla.org"
如果当前文档的域无法识别，那么 domain 属性会返回 null。
在根域范围内，Mozilla允许你把domain属性的值设置为它的上一级域。例如，在 developer.mozilla.org 域内，可以把domain设置为 "mozilla.org" 但不能设置为 "mozilla.com" 或者"org"。
因此，若两个源所用协议、端口一致，主域相同而二级域名不同的话，可以借鉴该方法解决跨域请求。
比如若我们在 a.github.io 页面执行以下语句：
document.domain = "github.io"
那么之后页面对 github.io
发起请求时页面则会成功通过对 github.io
的同源检测。比较直接的一个操作是，当我们在 a.github.io
页面中利用 iframe 去加载 github.io
时，通过如上的赋值后，我们可以在 a.github.io
页面中去操作 iframe 里的内容。
我们同时考虑另一种情况：存在两个子域名 a.github.io
以及 b.github.io
， 其中前者域名下网页 a.html 通过 iframe 引入了后者域名下的 b.html，此时在 a.html 中是无法直接操作 b.html 的内容的。
同样利用 document.domain
，我们在两个页面中均加入
document.domain='github.io'
这样在以上的 a.html 中就可以操作通过 iframe 引入的 b.html 了。
document.domain 的优点在于解决了主语相同的跨域请求，但是其缺点也是很明显的：比如一个站点受到攻击后，另一个站点会因此引起安全漏洞；若一个页面中引入多个 iframe，想要操作所有的 iframe 则需要设置相同的 domain。
location.hash
location.hash
是一个可读可写的字符串，该字符串是 URL 的锚部分（从 # 号开始的部分）。例如：
// 对于页面 http://example.com:1234/test.htm#part2location.hash = "#part2"
同时，由于我们知道改变 hash 并不会导致页面刷新，所以可以利用 hash 在不同源间传递数据。
假设 github.io
域名下 a.html 和 shaonian.eu
域名下 b.html 存在跨域请求，那么利用 location.hash 的一个解决方案如下：
a.html 页面中创建一个隐藏的 iframe， src 指向 b.html，其中 src 中可以通过 hash 传入参数给 b.html
b.html 页面在处理完传入的 hash 后通过修改 a.html 的 hash 值达到将数据传送给 a.html 的目的
a.html 页面添加一个定时器，每隔一定时间判断自身的 location.hash 是否变化，以此响应处理
以上步骤中需要注意第二点：如何在 iframe 页面中修改 父亲页面的 hash 值。由于在 IE 和 Chrome 下，两个不同域的页面是不允许 parent.location.hash
这样赋值的，所以对于这种情况，我们需要在父亲页面域名下添加另一个页面来实现跨域请求，具体如下：
假设 a.html 中 iframe 引入了 b.html, 数据需要在这两个页面之间传递，且 c.html 是一个与 a.html 同源的页面
a.html 通过 iframe 将数据通过 hash 传给 b.html
b.html 通过 iframe 将数据通过 hash 传给 c.html
c.html 通过 parent.parent.location.hash
设置 a.html 的 hash 达到传递数据的目的
location.bash メソッドの利点は、完全に異なるドメイン名によるクロスドメインリクエストを解決でき、双方向通信を実現できることですが、欠点としては次の点が挙げられます。
このメソッドを使用して転送されるデータ量は制限されています。 URL サイズと渡されるデータ型によって制限されます
データが URL で直接公開されるため、セキュリティ上の問題があります
ブラウザが onhashchange
イベントをサポートしていない場合は、ローテーション トレーニングを通じて URL の変更を学習する必要があります
ブラウザーはハッシュが変更されると履歴レコードを生成するため、ユーザー エクスペリエンスに影響を与える可能性があります
window.name
このプロパティは、ウィンドウの名前を取得/設定するために使用されます。その特徴は、ウィンドウのライフサイクル中、ウィンドウによってロードされたすべてのページがこの値を共有し、この属性に対する読み取りおよび書き込み権限を持っていることです。これは、値が変更されない場合、異なるページのロード間で値が変更されず、最大 2MB のストレージをサポートすることを意味します。
この機能を使用すると、次の手順でクロスドメインリクエストを解決できます:
b.github.io/b.html を指す iframe を a.github.io/a.html に作成します (ページは独自のウィンドウをアタッチします) .nameをiframeに)
iframeを監視するonloadイベントをa.github.io/a.htmlに追加し、このイベント内のローカルドメインのプロキシファイルにiframeのsrcを設定します(プロキシファイルとa.htmlは同一ドメイン内で相互に通信することができ、同時に iframe の name 値をデータ取得後に破棄してメモリを解放し、セキュリティも確保できるという利点があります。 window.name の利点は、ブラウザのクロスドメイン アクセス制限を巧みに回避していることですが、同時に別の安全な操作でもあります。
window.postMessage
APIの詳しい使い方についてはMDNをご覧ください。
JSONP
JSONP (正式名は JSON with Padding) は、AJAX を使用して実装されたさまざまなソースに対するクロスドメイン リクエストです。基本原則: Web ページは、<script><br/> 要素を追加することでサーバーに JSON データをリクエストします。このアプローチは、サーバーがリクエストを受信した後、データをコールバック関数に入れます。指定された名前を付けて送り返します。 <br/>以下は例です。test.jsが返す内容はコードとして直接実行されるため、a.htmlにcallback<br/>関数が定義されていればすぐに呼び出されます。 <br/>//現在のページ a.com/a.html<script type="text/javascript">//コールバック関数 function callback(data) {alert(data.message);}</script><スクリプト タイプ="text/javascript" src="http://b.com/test.js">// test.js// コールバック関数を呼び出し、それを json データの形式で渡します。コールバックを完了するための説明 callback({message:"success"});
スクリプトの柔軟性を確保するために、JavaScript を通じてスクリプト タグを動的に作成し、HTTP パラメーターを通じてコールバック関数名をサーバーに渡すことができます。
jQuery には、対応する JSONP 実装メソッドがあります。API を参照してください。
JSONP の利点は、シンプルで適用可能で、すべての古いブラウザでサポートされ、サーバーの変更がほとんど必要ないことです。 XMLHttpRequest や ActiveX のサポートは必要ありませんが、欠点は GET リクエストのみがサポートされていることです。
WebSocket プロトコルは同一オリジン ポリシーを実装していませんが、サーバーがサポートしている限り、それを介してクロスオリジン通信を実行できます。
CORS
CORS は W3C 標準であり、正式名称は「Cross-Origin Resource Sharing」です。これにより、ブラウザーがクロスオリジン サーバーに XMLHttpRequest リクエストを発行できるようになり、AJAX が同じオリジンからのみ使用できるという制限が克服されます。
クロスドメイン リソース共有 (CORS) メカニズムにより、Web アプリケーション サーバーがクロスドメイン アクセス制御を実行できるようになり、クロスドメイン データ送信を安全に実行できるようになります。サーバーとクライアントの両方からのサポートが必要です。
クロスオリジン共有標準により、次のシナリオでクロスオリジン HTTP リクエストの使用が許可されます:
Web フォント (クロスオリジン フォントは @font-face リソースを通じて CSS で使用されます) ) そのため、Web サイトは TrueType フォント リソースを公開し、承認された Web サイトのみがサイト間呼び出しを行うことができます
WebGL テクスチャ
drawImage を使用して画像/ビデオ画像をキャンバスに描画します
スタイル シート (CSSOM を使用)
スクリプト (未処理の例外)
CORS 存在以下三种主要场景，分别是简单请求，预检请求和附带身份凭证的请求。
简单请求：若只使用 GET, HEAD 或者 POST 请求，且除 CORS 安全的首部字段集合外，无人为设置该集合之外的其他首部字段，同时 Content-Type 值属于下列之一，那么该请求则可以被视为简单请求：
application/x-www-form-urlencodedmultipart/form-datatext/plain
此情况下，若服务端返回的 Access-Control-Allow-Origin: *
，则表明该资源可以被任意外域访问。若要指定仅允许来自某些域的访问，需要将 *
设定为该域，例如：
Access-Control-Allow-Origin: http://foo.example
预检请求：与前述简单请求不同，该要求必须首先使用 OPTIONS 方法发起一个预检请求到服务器，以获知服务器是否允许该实际请求。当请求满足以下三个条件任意之一时， 即应首先发送预检请求：
使用了 PUT, DELETE, CONNECT, OPTIONS, TRACE, PATCH 中任一的 HTTP 方法
人为设置了对 CORS 安全的首部字段集合之外的其他首部字段
Content-Type 的值不属于下列之一
application/x-www-form-urlencodedmultipart/form-datatext/plain
预检请求完成之后（通过 OPTIONS 方法实现），才发送实际请求。一个示范 HTTP 请求如下所示：
var invocation = new XMLHttpRequest();
var url = 'http://bar.other/resources/post-here/';
var body = '<?xml version="1.0"?><person><name>Arun</name></person>';
function callOtherDomain(){ if(invocation) { invocation.open('POST', url, true);
invocation.setRequestHeader('X-PINGOTHER', 'pingpong');
invocation.setRequestHeader('Content-Type', 'application/xml');
invocation.onreadystatechange = handler;
invocation.send(body); }}附带身份凭证的请求：这种方式的特点在于能够在跨域请求时向服务器发送凭证请求，例如 Cookies (withCredentials 标志设置为 true)。
一般而言，对于跨域 XMLHttpRequest 或 Fetch 请求，浏览器不会发送身份凭证信息。如果要发送凭证信息，需要设置 XMLHttpRequest 的某个特殊标志位。但是需要注意的是，如果服务器端的响应中未携带 Access-Control-Allow-Credentials: true
，浏览器将不会把响应内容返回给请求的发送者。
附带身份凭证的请求与通配符
对于附带身份凭证的请求，服务器不得设置 Access-Control-Allow-Origin 的值为“”。
这是因为请求的首部中携带了 Cookie 信息，如果 Access-Control-Allow-Origin 的值为“”，请求将会失败。而将 Access-Control-Allow-Origin 的值设置为 foo.example，则请求将成功执行。
另外，响应首部中也携带了 Set-Cookie 字段，尝试对 Cookie 进行修改。如果操作失败，将会抛出异常。
MDN 引例如下：
var invocation = new XMLHttpRequest();
var url = 'http://bar.other/resources/credentialed-content/';
function callOtherDomain(){ if(invocation) { invocation.open('GET', url, true);
invocation.withCredentials = true; invocation.onreadystatechange = handler; invocation.send(); }}其实由上我们知道，CORS 的优点也非常明显：CORS支持所有类型的HTTP请求，是跨域HTTP请求的根本解决方案。
以上就是所有的跨域请求解决方案，根据实际生产环境，总有一款适合你。
本篇讲解了跨域的相关解决方法，更多相关内容请关注php中文网。
相关推荐：
以上がフロントエンド向けの一般的なクロスドメイン ソリューション (すべて)の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
