Home > Article > Web Front-end > Common cross-domain solutions for front-end (all)
I often see cross-domain related content in my studies. This article will provide cross-domain solutions for the star realm.
Cross-domain solution
1. Cross-domain via jsonp
2. Document.domain iframe cross-domain
3. Location.hash iframe
4. Window.name iframe cross-domain
5. postMessage cross-domain
6. Cross-domain resource sharing (CORS)
7. nginx proxy cross-domain
8. nodejs middleware proxy cross-domain
9. WebSocket protocol cross-domain
1. Cross-domain through jsonp
Usually in order to reduce the load on the web server, we separate static resources such as js, css, img, etc. to another server with an independent domain name, and then use the corresponding tags in the html page from Loading static resources under different domain names is allowed by the browser. Based on this principle, we can dynamically create a script and then request a URL with parameters to achieve cross-domain communication.
1.) Native implementation:
<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>
The server returns as follows (the global function is executed when returning):
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); })
Backend node.js code example:
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 Disadvantages: Only one kind of get request can be implemented.
2. document.domain iframe cross-domain
This solution is limited to cross-domain application scenarios where the main domain is the same but the subdomains are different.
Implementation principle: Both pages forcefully set document.domain as the basic main domain through js, thus achieving the same domain.
1.) Parent window: (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>
2.) Child window: ([http://child.domain.com/ b.html)
<script> document.domain = 'domain.com'; // 获取父窗口中变量 alert('get js data from parent ---> ' + window.parent.user);</script>
3. location.hash iframe cross-domain
Implementation principle: a wants to communicate with b across domains, through the intermediate page c. For three pages, the location.hash of iframe is used to transfer values between different domains, and direct js access is used to communicate between the same domains.
Specific implementation: A domain: a.html -> B domain: b.html -> A domain: c.html, different domains a and b can only communicate one-way through hash values, b and c are also different Domains can only communicate in one direction, but c and a are in the same domain, so c can access all objects on the a page through 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);
// Open to the callback method function onCallback(res) of the same domain c.html ) { alert('data from c.html ---> ' res); }2cacc6d41bbb37262a98f745aa00fbf0
2.) b.html: (http://www.domain2. com/b.html))
7d8fd55240d5699e55fd4bb370312a84891af37500392f05ebb1c8a2a6aafd553f1c4e4b6b16bbbd69b2ee476dc4f83a var iframe = document.getElementById('iframe');
// Monitor the hash value passed by a.html and then pass it to c.htmlwindow.onhashchange = function () {
iframe.src = iframe.src location.hash;
};2cacc6d41bbb37262a98f745aa00fbf0
3.) c.html: (http://www.domain1.com/c. html))
3f1c4e4b6b16bbbd69b2ee476dc4f83a // Monitor the hash value from b.html
window.onhashchange = function () { // Then operate the js callback of a.html in the same domain to change The result is returned to window.parent.parent.onCallback('hello: ' location.hash.replace('#user=', '')); };2cacc6d41bbb37262a98f745aa00fbf0
4. window.name iframe cross-domain
The uniqueness of the window.name attribute: the name value still exists after different pages (or even different domain names) are loaded, and can support very long name values (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);
// After obtaining the data, destroy the iframe and release the memory; this also ensures safety (Not accessed by other domain frame js) function destoryFrame() {
iframe.contentWindow.document.write(''); iframe.contentWindow.close(); document.body.removeChild(iframe); }
};//Request cross-domain b page data proxy('http://www.domain2.com/b.html ', function(data){
alert(data);
});
2.) proxy.html: (http://www.domain1.com/proxy. ...) The intermediate proxy page is in the same domain as a.html, and the content can be empty.
3.) b.html: (http://www.domain2.com/b.html))
<script> window.name = 'This is domain2 data!';</script>
Summary: Through the src attribute of iframe, it is transferred from the external domain to the local domain, and the cross-domain data is The window.name of the iframe is passed from the external domain to the local domain. This cleverly bypasses the browser's cross-domain access restrictions, but at the same time it is a safe operation.
5. postMessage cross-domain
postMessage is an API in HTML5 XMLHttpRequest Level 2, and is one of the few window attributes that can be operated across domains. It can be used to solve the following problems: a.) Page and Data transfer of the new window it opens b.) Message transfer between multiple windows c.) Page and nested iframe message transfer d.) Cross-domain data transfer of the above three scenarios
Usage: postMessage(data, origin ) method accepts two parameters data: The HTML5 specification supports any basic type or copyable object, but some browsers only support strings, so it is best to use JSON.stringify() serialization when passing parameters. Origin: protocol host port number, can also be set to "*", which means it can be passed to any window. If you want to specify the same origin as the current window, set it to "/".
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>
2.) b.html: (http://www.domain2.com /b.html))
<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 达到传递数据的目的
The advantage of the location.bash method is that it can solve cross-domain requests with completely different domain names and can achieve two-way communication; the disadvantages include the following points:
The amount of data transferred using this method is limited by the URL size , the type of data passed is limited
There are security issues since the data is directly exposed in the URL
If the browser does not support the onhashchange
event, you need to learn the changes in the URL through rotation training
Some browsers will A history record is generated when the hash changes, so it may affect the user experience
window.name
This property is used to get/set the name of the window. Its characteristic is that during the life cycle of a window, all pages loaded by the window share this value and have read and write permissions to this attribute. This means that if the value is not modified, it will not change between different page loads, and it supports storage of up to 2MB.
Using this feature, we can solve cross-domain requests with the following steps:
Create an iframe in a.github.io/a.html and point it to b.github.io/b.html (the page will change its own window .name attached to the iframe)
Add the onload event of the iframe to a.github.io/a.html, and in this event set the src of the iframe to the proxy file of the local domain (the proxy file and a.html are in Under the same domain, they can communicate with each other), and at the same time, the name value of the iframe can be sent out.
Destroy the iframe after obtaining the data, release the memory, and also ensure security.
The advantage of window.name is that it cleverly bypasses It overcomes the browser's cross-domain access restrictions, but at the same time it is a safe operation.
window.postMessage
HTML5 In order to solve this problem, a new API is introduced: cross-document communication API (Cross-document messaging). This API adds a new window.postMessage method to the window object, allowing cross-window communication, regardless of whether the two windows have the same origin.
For detailed usage of API, please see MDN.
JSONP
JSONP, the full name is JSON with Padding, is a cross-domain request from different sources implemented using AJAX. The basic principle: the web page requests JSON data from the server by adding a 3f1c4e4b6b16bbbd69b2ee476dc4f83a
element. This approach is not restricted by the same-origin policy; after the server receives the request, it places the data in a callback function with a specified name. Pass it back.
The following is an example. Since the content returned by test.js is run directly as code, as long as the callback
function is defined in a.html, it will be called immediately.
//Current page a.com/a.html4ec11beb6c39d0703d1751d203c17053//Callback function function callback(data) { alert(data.message);}2cacc6d41bbb37262a98f745aa00fbf0f7eaeff216fe3911cfa28b0d821be9e72cacc6d41bbb37262a98f745aa00fbf0// test.js// Call the callback function and pass it as json data as the description, Completion callback callback({message:"success"});
In order to ensure the flexibility of the script, we can dynamically create script tags through JavaScript and pass the callback function name to the server through HTTP parameters. The case is as follows :
4ec11beb6c39d0703d1751d203c17053 // Method to add 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(){ // Search for apple and pass the custom callback function name result into the callback parameter in addScriptTag("http://ajax.googleapis.com/ajax/services/search/web?v=1.0&q=apple&callback=result"); } // Customized callback function result function result(data) { // We simply obtain the url data in the first record of apple search results alert(data.responseData.results[0].unescapedUrl); }2cacc6d41bbb37262a98f745aa00fbf0
jQuery has a corresponding JSONP implementation method , see API.
The advantage of JSONP is that it is simple and applicable, supported by all old browsers, and requires little server modification. No support for XMLHttpRequest or ActiveX is required; the disadvantage is that only GET requests are supported.
WebSocket
The WebSocket protocol does not implement a same-origin policy. As long as the server supports it, cross-origin communication can be carried out through it.
CORS
CORS is a W3C standard, whose full name is "Cross-origin resource sharing". It allows the browser to issue XMLHttpRequest requests to cross-origin servers, thus overcoming the limitation that AJAX can only be used from the same origin.
Cross-domain resource sharing (CORS) mechanism allows web application servers to perform cross-domain access control, so that cross-domain data transmission can be carried out securely. It requires support from both the server and the client.
The cross-origin sharing standard allows the use of cross-origin HTTP requests in the following scenarios:
Cross-origin HTTP requests initiated by XMLHttpRequest or Fetch
Web fonts (via @font in CSS -face uses cross-domain font resources), so websites can publish TrueType font resources and only allow authorized websites to make cross-site calls
WebGL texture
Use drawImage to draw Images/video pictures to canvas
Stylesheets (using CSSOM)
Scripts (Unhandled exceptions)
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中文网。
相关推荐:
The above is the detailed content of Common cross-domain solutions for front-end (all). For more information, please follow other related articles on the PHP Chinese website!