Maison > Article > interface Web > Solutions inter-domaines communes pour le front-end (tous)
Je vois souvent du contenu inter-domaines dans mes études. Cet article fournira des solutions inter-domaines pour le royaume des étoiles.
Solution inter-domaines
1. Inter-domaine via jsonp
2 Document.domain + iframe cross-domain
3. nom + iframe cross-domain
5. postMessage cross-domain
6. Partage de ressources inter-domaines (CORS)
7. proxy nginx cross-domain
8. 🎜>9. Protocole WebSocket Cross-domain
1. Cross-domain via jsonp
Habituellement, afin de réduire la charge du serveur Web, nous séparons les ressources statiques telles que js, css, img, etc. serveur avec un nom de domaine indépendant, puis transmettre la balise correspondante. La balise charge les ressources statiques de différents noms de domaine et est autorisée par le navigateur. Sur la base de ce principe, nous pouvons créer dynamiquement un script puis demander une URL avec des paramètres pour réaliser des croisements. communication de domaine.
1.) Implémentation native :
<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: {}});Code backend node.js exemple :
3.)vue.js: this.$http.jsonp('http://www.domain2.com:8080/login', { params: {}, jsonp: 'onBack'}).then((res) => { console.log(res); })jsonp Inconvénients : un seul type de requête get peut être implémenté.
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...');2. document.domain + iframe cross-domain
Cette solution est limitée aux scénarios d'application multi-domaines où le domaine principal est le même mais les sous-domaines sont différents.
Principe de mise en œuvre : les deux pages définissent de force document.domain comme domaine principal de base via js, obtenant ainsi le même domaine.
1.) Fenêtre parent : (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>3. Location.hash + iframe cross-domain
<script> document.domain = 'domain.com'; // 获取父窗口中变量 alert('get js data from parent ---> ' + window.parent.user);</script>Principe de mise en œuvre : Si a souhaite communiquer avec b à travers les domaines, cela se fait via la page intermédiaire c. Pour trois pages, le location.hash de l'iframe est utilisé pour transférer des valeurs entre différents domaines, et l'accès direct js est utilisé pour communiquer entre les mêmes domaines.
Implémentation spécifique : Domaine A : a.html -> Domaine B : b.html -> Domaine A : c.html, les différents domaines a et b ne peuvent communiquer que dans un sens, via les valeurs de hachage, b et c le sont. de plus, des domaines différents ne peuvent communiquer que dans une seule direction, mais c et a sont dans le même domaine, donc c peut accéder à tous les objets de la page a via parent.parent.
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);
2.) b.html : (http:/ /www .domain2.com/b.html))
7c550ca04dba160e1269736535776ea83f1c4e4b6b16bbbd69b2ee476dc4f83a var iframe = document.getElementById('iframe');
// Surveillez la valeur de hachage de a.html et transmettez-la à c.htmlwindow.onhashchange = function () {iframe.src = iframe.src + location.hash;
};2cacc6d41bbb37262a98f745aa00fbf0
3.) c.html : (http://www.domain1 .com/c.html))
3f1c4e4b6b16bbbd69b2ee476dc4f83a // Surveiller la valeur de hachage de b.html
window.onhashchange = function () { // Puis exploiter le même domaine a.html js rappel, transférez le résultat vers window.parent.parent.onCallback('hello: ' + location.hash.replace('#user=', ''));2cacc6d41bbb37262a98f745aa00fbf0
4. window.name + iframe cross-domain
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;// Après avoir obtenu les données, détruisez l'iframe et libérez la mémoire ; Cela garantit également la sécurité (non accessible par d'autres frame js de domaine) function destoryFrame() {
// 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.contentWindow.document.write(''); iframe.contentWindow.close(); document.body.removeChild(iframe); }alert(data);
});
2.) proxy.html : (http : //www .domain1.com/proxy....) La page proxy intermédiaire est dans le même domaine que a.html et le contenu peut être vide.
<script> window.name = 'This is domain2 data!';</script>5. postMessage inter-domaines
postMessage est une API en HTML5 XMLHttpRequest niveau 2 et est l'un des rares attributs de fenêtre pouvant être utilisé sur plusieurs domaines. Transfert de page et de données dans la nouvelle fenêtre qu'il ouvre b.) Transfert de messages entre plusieurs fenêtres c.) Transfert de pages et de messages iframe imbriqués d.) Transfert de données inter-domaines dans les trois scénarios ci-dessus
Utilisation : postMessage(data, origin ) accepte deux données de paramètres : la spécification HTML5 prend en charge tout type de base ou objet copiable, mais certains navigateurs ne prennent en charge que les chaînes, il est donc préférable d'utiliser la sérialisation JSON.stringify() lors du passage des paramètres. Origine : protocole + hôte + numéro de port, il peut également être défini sur "*", ce qui signifie qu'il peut être transmis à n'importe quelle fenêtre. Si vous souhaitez spécifier la même origine que la fenêtre actuelle, définissez-la sur "/".
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 达到传递数据的目的
L'avantage de la méthode location.bash est qu'elle peut résoudre des requêtes inter-domaines avec des noms de domaine complètement différents et permettre une communication bidirectionnelle. Les inconvénients incluent les points suivants :
La quantité de données transférées à l'aide de cette méthode ; La méthode est limitée par la taille de l'URL, le type de données transmis est limité
Étant donné que les données sont directement exposées dans l'URL, il existe des problèmes de sécurité
Si le navigateur ne prend pas en charge l'événement onhashchange
, vous devez pour apprendre les modifications apportées à l'URL grâce à une formation en rotation
Certains navigateurs Un enregistrement d'historique est généré lorsque le hachage change, cela peut donc affecter l'expérience utilisateur
window.name
Cette propriété est utilisée pour obtenir/définir le nom de la fenêtre. Sa particularité est que durant le cycle de vie d'une fenêtre, toutes les pages chargées par la fenêtre partagent cette valeur et disposent des autorisations de lecture et d'écriture sur cet attribut. Cela signifie que si la valeur n'est pas modifiée, elle ne changera pas entre les différents chargements de page et prend en charge un stockage jusqu'à 2 Mo.
Grâce à cette fonctionnalité, nous pouvons résoudre les requêtes inter-domaines en suivant les étapes suivantes :
Créez une iframe dans a.github.io/a.html pointant vers b.github.io/b.html (la page sera utiliser sa propre fenêtre .name attachée à l'iframe)
Ajoutez l'événement onload de l'iframe à a.github.io/a.html, et dans cet événement définissez le src de l'iframe sur le fichier proxy du domaine local (le fichier proxy et a.html sont dans le même domaine, ils peuvent communiquer entre eux), et en même temps, la valeur du nom de l'iframe peut être envoyée
Après avoir obtenu les données, détruisez l'iframe et libérez la mémoire, tout en assurant également la sécurité
L'avantage de window.name est qu'il contourne intelligemment. Il surmonte les restrictions d'accès inter-domaines du navigateur, mais en même temps c'est une opération sûre.
window.postMessage
HTML5 introduit une nouvelle API pour résoudre ce problème : Cross-document Messaging API (Cross-document Messaging). Cette API ajoute une nouvelle méthode window.postMessage à l'objet window, permettant la communication entre fenêtres, que les deux fenêtres aient ou non la même origine.
Pour une utilisation détaillée de l'API, veuillez consulter MDN.
JSONP
JSONP, le nom complet est JSON with Padding, est une requête inter-domaines qui utilise AJAX pour implémenter des requêtes provenant de différentes sources. Le principe de base : la page Web demande des données JSON au serveur en ajoutant un élément 3f1c4e4b6b16bbbd69b2ee476dc4f83a
. Cette approche n'est pas limitée par la politique de même origine une fois que le serveur a reçu la requête, il place les données dans un fichier. fonction de rappel avec un nom spécifié.
Ce qui suit est un exemple. Puisque le contenu renvoyé par test.js est exécuté directement sous forme de code, tant que la fonction callback
est définie dans a.html, elle sera appelée immédiatement.
//Page actuelle a.com/a.html4ec11beb6c39d0703d1751d203c17053//Callback function function callback(data) { alert(data.message);}2cacc6d41bbb37262a98f745aa00fbf0f7eaeff216fe3911cfa28b0d821be9e72cacc6d41bbb37262a98f745aa00fbf0// test.js// Appelez la fonction de rappel et transmettez-la sous forme de données json comme description , Achèvement du rappel callback({message:"success"});
Afin de garantir la flexibilité du script, nous pouvons créer dynamiquement des balises de script via JavaScript et transmettre le nom de la fonction de rappel au serveur via les paramètres HTTP Le cas est le suivant :
4ec11beb6c39d0703d1751d203c17053 // Méthode d'ajout de 3f1c4e4b6b16bbbd69b2ee476dc4f83a tag function addScriptTag(src){ var script = document.createElement('script'); script.setAttribute("type ","text/javascript"); script.src = src; document.body.appendChild(script); } window.onload = function(){ // Recherchez apple et transmettez la fonction de rappel personnalisée name result dans le paramètre de rappel dans addScriptTag("http://ajax.googleapis.com/ajax/services/search/web?v=1.0&q=apple&callback=result" } // Résultat de la fonction de rappel personnalisé function result(data) ) { // Nous obtenons simplement les données URL dans le premier enregistrement de l'alerte des résultats de recherche Apple (data.responseData.results[0].unescapedUrl); }2cacc6d41bbb37262a98f745aa00fbf0
jQuery a l'implémentation JSONP correspondante); méthode , voir API.
L'avantage de JSONP est qu'il est simple et applicable, tous les anciens navigateurs le prennent en charge et la modification du serveur est minime. Aucune prise en charge de XMLHttpRequest ou d'ActiveX n'est requise ; l'inconvénient est que seules les requêtes GET sont prises en charge.
WebSocket
Le protocole WebSocket n'implémente pas de politique de même origine tant que le serveur le prend en charge, la communication entre origines peut être effectuée via celui-ci.
CORS
CORS est une norme du W3C, son nom complet est "Partage de ressources cross-origin". Il permet au navigateur d'émettre des requêtes XMLHttpRequest vers des serveurs d'origines croisées, surmontant ainsi la limitation selon laquelle AJAX ne peut être utilisé qu'à partir de la même origine.
Le mécanisme CORS (Cross-Origin Resource Sharing) permet aux serveurs d'applications Web d'effectuer un contrôle d'accès entre domaines, permettant ainsi d'effectuer en toute sécurité la transmission de données entre domaines. Cela nécessite le support du serveur et du client.
Le standard de partage d'origine croisée permet l'utilisation de requêtes HTTP d'origine croisée dans les scénarios suivants :
Requêtes HTTP d'origine croisée initiées par XMLHttpRequest ou Fetch
Polices Web (via @font en CSS -face utilise ressources de polices inter-domaines), afin que les sites Web puissent publier des ressources de polices TrueType et autoriser uniquement les sites Web autorisés à effectuer des appels intersites
Textures WebGL
Utilisez drawImage pour dessiner des images/écrans vidéo sur le canevas
Feuilles de style (en utilisant CSSOM )
Scripts (exceptions non gérées)
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中文网。
相关推荐:
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!