「深入浅出」前端开发中常用的几种跨域解决方案

看完本文可以系统地掌握，不同种跨域解决方案间的巧妙，以及它们的用法、原理、局限性和适用的场景

按需网站开发可以根据自己的需求进行定制，网站建设、网站制作构思过程中功能建设理应排到主要部位公司网站建设、网站制作的运用实际效果公司网站制作网站建立与制做的实际意义

包括以下几个方面：

跨域的现象，和几种常见的跨域表现
跨域的解决方案（原理分析）
修改本地HOST
JSONP
CORS
Proxy
Nginx反向代理
Post Message（利用iframe标签，实现不同域的关联）
同源是什么？
如果两个URL的协议protocol、主机名host和端口号port都相同的话，则这两个URL是同源。

同源策略
同源策略是一个重要的安全策略。它能够阻断恶意文档，减少被攻击的媒介。

真实项目中，很少有同源策略，大部分都是非同源策略

跨域是什么？
当协议、域名与端口号中任意一个不相同时，都算作不同域，不同域之间相互请求资源的表现(非同源策略请求)，称作”跨域“。

跨域现象
那么我们就下面的网址分析一下，哪一块是协议，哪一块是域名及端口号 

 
 
 
 
    
  
  
  
  
  1. http://kbs.sports.qq.com/index.html 
    2. 
  
  
  
  
  2.  
    3. 
  
  
  
  
  3. 协议：http(还有以一种https协议) 
    4. 
  
  
  
  
  4. 域名：kbs.sports.qq.com 
    5. 
  
  
  
  
  5. 端口号：80 
    6. 
  
  
  
  
  6.  
    7. 
  
  
  
  
  7. https://127.0.0.1:3000 
    8. 
  
  
  
  
  8.  
    9. 
  
  
  
  
  9. 协议：https 
    10. 
  
  
  
  
  10. 域名：127.0.0.1 
    11. 
  
  
  
  
  11. 端口号：3000 
    12.

假如我们的真实项目开发中的Web服务器地址为 ”http://kbs.sports.qq.com/index.html“，而需要请求的数据接口地址为 "http://api.sports.qq.com/list"。

当Web服务器的地址向数据接口的地址发送请求时，便会造成了跨域现象

造成跨域的几种常见表现
服务器分开部署（Web服务器 + 数据请求服务器）
本地开发（本地预览项目 调取 测试服务器的数据）
调取第三方平台的接口
Web服务器：主要用来静态资源文件的处理

解决方案

 
 
 
 
    
  
  
  
  
  1. 修改本地HOST(不作介绍) 
    2. 
  
  
  
  
  2. JSONP 
    3. 
  
  
  
  
  3. CORS 
    4. 
  
  
  
  
  4. Proxy 
    5. 
  
  
  
  
  5. Nginx反向代理 
    6. 
  
  
  
  
  6. Post Message（利用iframe标签，实现不同域的关联） 
    7.

在后面会详细分析这四种解决方案的原理和用法配置，以及它们的优点和局限性

 
 
 
 
    
  
  
  
  
  1. 注意： 基于ajax或fetch发送请求时，如果是跨域的，则浏览器默认的安全策略会禁止该跨域请求 
    2. 
 
 
 
 

 
 
 
 
    
  
  
  
  
  1. 补充说明：以下所有的测试用例，均由Web：http://127.0.0.1:5500/index.html向API：http://127.0.0.1:1001/list发起请求 
    2.

API接口的服务器端是自己通过express建立的，下文在服务器端以app.use中间件的形式接受来自客户端的请求并做处理。

 
 
 
 
    
  
  
  
  
  1. 即 在“http://127.0.0.1:1001/list”from origin“http://127.0.0.1:55”上对XMLHttpRequest的访问已被CORS策略阻止:被请求的资源上没有“Access- control - allow-origin”头 
    2.

在后端开启了一个端口号为1001的服务器之后，我们来实践一下

 
 
 
 
    
  
  
  
  
  1. let xhr = new XMLHttpRequest; 
    2. 
  
  
  
  
  2. xhr.open('get', 'http://127.0.0.1:1001/list'); 
    3. 
  
  
  
  
  3. xhr.onreadystatechange = () => { 
    4. 
  
  
  
  
  4.   if (xhr.status === 200 && xhr.readyState === 4) { 
    5. 
  
  
  
  
  5.     console.log(xhr.responseText); 
    6. 
  
  
  
  
  6.   } 
    7. 
  
  
  
  
  7. }; 
    8. 
  
  
  
  
  8. xhr.send();  
    9.

跨域的常见报错提示
这就是由于浏览器默认的安全策略禁止导致的。

下面介绍一下几种常见的解决方案。

JSONP
原理：JSONP利用script标签不存在域的限制，且定义一个全局执行上下文中的函数func

（用来接收服务器端返回的数据信息）来接收数据，从而实现跨域请求。

 
 
 
 
    
  
  
  
  
  1. 弊端： 
    2. 
  
  
  
  
  2.  
    3. 
  
  
  
  
  3. 只允许GET请求 
    4. 
  
  
  
  
  4. 不安全：只要浏览器支持，且存在浏览器的全局变量里，则谁都可以调用 
    5.

图解JSONP的原理

手动封装JSONP
callback必须是一个全局上下文中的函数

（防止不是全局的函数，我们需要把这个函数放在全局上，并且从服务器端接收回信息时，要浏览器执行该函数）

注意：

uniqueName变量存储全局的回调函数（确保每次的callback都具有唯一性）
检验url中是否含有"?"，有的话直接拼接callback，没有的话补”？“

 
 
 
 
    
  
  
  
  
  1. // 客户端 
    2. 
  
  
  
  
  2. function jsonp(url, callback) { 
    3. 
  
  
  
  
  3.   // 把传递的回调函数挂载到全局上 
    4. 
  
  
  
  
  4.  let uniqueName = `jsonp${new Date().getTime()}`; 
    5. 
  
  
  
  
  5.   // 套了一层 anonymous function 
    6. 
  
  
  
  
  6.   // 目的让 返回的callback执行且删除创建的标签 
    7. 
  
  
  
  
  7.   window[uniqueName] = data => { 
    8. 
  
  
  
  
  8.   // 从服务器获取结果并让浏览器执行callback 
    9. 
  
  
  
  
  9.     document.body.removeChild(script); 
    10. 
  
  
  
  
  10.     delete window[uniqueName]; 
    11. 
  
  
  
  
  11.     callback && callback(data); 
    12. 
  
  
  
  
  12.   } 
    13. 
  
  
  
  
  13.    
    14. 
  
  
  
  
  14.   // 处理URL 
    15. 
  
  
  
  
  15.   url += `${url.includes('?')} ? '&' : '?}callback=${uniqueName}'`; 
    16. 
  
  
  
  
  16.    
    17. 
  
  
  
  
  17.   // 发送请求 
    18. 
  
  
  
  
  18.   let script = document.createElement('script'); 
    19. 
  
  
  
  
  19.   script.src = url; 
    20. 
  
  
  
  
  20.   document.body.appendChild(script); 
    21. 
  
  
  
  
  21. } 
    22. 
  
  
  
  
  22.  
    23. 
  
  
  
  
  23. // 执行第二个参数 callback，获取数据 
    24. 
  
  
  
  
  24. jsonp('http://127.0.0.1:1001/list?userName="lsh"', (result) => { 
    25. 
  
  
  
  
  25.  console.log(result); 
    26. 
  
  
  
  
  26. }) 
    27. 
 
 
 
 
 
 
 
 
    
  
  
  
  
  1. // 服务器端 
    2. 
  
  
  
  
  2. // Api请求数据 
    3. 
  
  
  
  
  3. app.get('/list', (req, res) => { 
    4. 
  
  
  
  
  4.    
    5. 
  
  
  
  
  5.   // req.query 问号后面传递的参数信息 
    6. 
  
  
  
  
  6.   // 此时的callback 为传递过来的函数名字 (uniqueName) 
    7. 
  
  
  
  
  7.  let { callback } = req.query; 
    8. 
  
  
  
  
  8.    
    9. 
  
  
  
  
  9.   // 准备返回的数据（字符串） 
    10. 
  
  
  
  
  10.   let res = { code: 0, data: [10,20] }; 
    11. 
  
  
  
  
  11.   let str = `${callback}($(JSON.stringify(res)))`; 
    12. 
  
  
  
  
  12.    
    13. 
  
  
  
  
  13.   // 返回给客户端数据 
    14. 
  
  
  
  
  14.   res.send(str); 
    15. 
  
  
  
  
  15. }) 
    16.

测试用例展示：

客户端请求的url
服务端返回的数据
返回的callback
返回的数据信息 result

 
 
 
 
    
  
  
  
  
  1. // 服务器请求的 url 
    2. 
  
  
  
  
  2. Request URL: 
    3. 
  
  
  
  
  3.  http://127.0.0.1:1001/list?userName="lsh"&callback=jsonp159876002 
    4. 
  
  
  
  
  4.  
    5. 
  
  
  
  
  5. // 服务器返回的函数callback 
    6. 
  
  
  
  
  6.  jsonp159876002({"code":0, "data": [10,20]}); 
    7. 
  
  
  
  
  7.  
    8. 
  
  
  
  
  8. // 客户端接收的数据信息 
    9. 
  
  
  
  
  9. { code: 0, data: Array(2) } 
    10.

当浏览器发现返回的是jsonp159876002({"code":0, "data": [10,20]});这个函数，会自动帮我们执行的。

JSONP弊端
在上文中说到只要服务器端那里设置了允许通过jsonp的形式跨域请求，我们就可以取回数据。

下面是在我们封装完jsonp方法之后，向一个允许任何源向该服务器发送请求的网址xxx

 
 
 
 
    
  
  
  
  
  1. jsonp('https://matchweb.sports.qq.com/matchUnion/cateColumns?from=pc', result => { 
    2. 
  
  
  
  
  2.   console.log(result); 
    3. 
  
  
  
  
  3. }); 
    4.

CORS
上文提到，不允许跨域的根本原因是因为Access-Control-Allow-Origin已被禁止

那么只要让服务器端设置允许源就可以了

原理：解决掉浏览器的默认安全策略，在服务器端设置允许哪些源请求就可以了

先来看一下下面的设置有哪些问题

 
 
 
 
    
  
  
  
  
  1. // 服务器端 
    2. 
  
  
  
  
  2. app.use((req, res, next) => { 
    3. 
  
  
  
  
  3.  // * 允许所有源（不安全/不能携带资源凭证） 
    4. 
  
  
  
  
  4.  res.header("Access-Control-Allow-Origin", "*"); 
    5. 
  
  
  
  
  5.  res.header("Access-Control-Allow-Credentials", true); 
    6. 
  
  
  
  
  6.  
    7. 
  
  
  
  
  7.  /* res.header("Access-Control-Allow-Headers", "Content-Type,...."); 
    8. 
  
  
  
  
  8.  res.header("Access-Control-Allow-Methods", "GET,..."); */ 
    9. 
  
  
  
  
  9.  
    10. 
  
  
  
  
  10.  // 试探请求：在CORS跨域请求中，首先浏览器会自己发送一个试探请求，验证是否可以和服务器跨域通信，服务器返回200，则浏览器继续发送真实的请求 
    11. 
  
  
  
  
  11.  req.method === 'OPTIONS' ? res.send('CURRENT SERVICES SUPPORT CROSS DOMAIN REQUESTS!') : next(); 
    12. 
  
  
  
  
  12. }); 
    13. 
  
  
  
  
  13.  
    14. 
  
  
  
  
  14. // 客户端 
    15. 
  
  
  
  
  15. let xhr = new XMLHttpRequest; 
    16. 
  
  
  
  
  16. xhr.open('get', 'http://127.0.0.1:1001/list'); 
    17. 
  
  
  
  
  17. xhr.setRequestHeader('Cookie', 'name=jason'); 
    18. 
  
  
  
  
  18. xhr.withCredentials = true; 
    19. 
  
  
  
  
  19. xhr.onreadystatechange = () => { 
    20. 
  
  
  
  
  20.   if (xhr.status === 200 && xhr.readyState === 4) { 
    21. 
  
  
  
  
  21.     console.log(xhr.responseText); 
    22. 
  
  
  
  
  22.   } 
    23. 
  
  
  
  
  23. }; 
    24. 
  
  
  
  
  24. xhr.send(); 
    25.

当我们一旦在服务器端设置了允许任何源可以请求之后，其实请求是不安全的，并且要求客户端不能携带资源凭证（比如上文中的Cookie字段），浏览器端会报错。

告诉我们Cookie字段是不安全的也不能被设置的，如果允许源为'*'的话也是不允许的。

假如在我们的真实项目开发中

正确写法

设置单一源（安全/也可以携带资源凭证/只能是单一一个源）
也可以动态设置多个源：每一次请求都会走这个中间件，我们首先设置一个白名单，如果当前客户端请求的源在白名单中，我们把Allow-Origin动态设置为当前这个源

 
 
 
 
    
  
  
  
  
  1. app.use((req, res, next) => { 
    2. 
  
  
  
  
  2.    
    3. 
  
  
  
  
  3.   // 也可自定义白名单，检验请求的源是否在白名单里，动态设置 
    4. 
  
  
  
  
  4.   /* let safeList = [ 
    5. 
  
  
  
  
  5.   "http://127.0.0.1:5500", 
    6. 
  
  
  
  
  6.   xxx, 
    7. 
  
  
  
  
  7.   xxxxx, 
    8. 
  
  
  
  
  8.  ]; */ 
    9. 
  
  
  
  
  9.  res.header("Access-Control-Allow-Origin", "http://127.0.0.1:5500"); 
    10. 
  
  
  
  
  10.  res.header("Access-Control-Allow-Credentials", true); // 设置是否可携带资源凭证 
    11. 
  
  
  
  
  11.  
    12. 
  
  
  
  
  12.  /* res.header("Access-Control-Allow-Headers", "Content-Type,...."); 
    13. 
  
  
  
  
  13.  res.header("Access-Control-Allow-Methods", "GET,..."); */ 
    14. 
  
  
  
  
  14.  
    15. 
  
  
  
  
  15.  // 试探请求：在CORS跨域请求中，首先浏览器会自己发送一个试探请求，验证是否可以和服务器跨域通信，服务器返回200，则浏览器继续发送真实的请求 
    16. 
  
  
  
  
  16.  req.method === 'OPTIONS' ? res.send('CURRENT SERVICES SUPPORT CROSS DOMAIN REQUESTS!') : next(); 
    17. 
  
  
  
  
  17. }); 
    18.

CORS的好处
原理简单，容易配置，允许携带资源凭证
仍可以用 ajax作为资源请求的方式
可以动态设置多个源，通过判断，将Allow-Origin设置为当前源
CORS的局限性
只允许某一个源发起请求
如多个源，还需要动态判断
Proxy
Proxy翻译为“代理”，是由webpack配置的一个插件，叫"webpack-dev-server"（只能在开发环境中使用）

Proxy在webpack中的配置

 
 
 
 
    
  
  
  
  
  1. const path = require('path'); 
    2. 
  
  
  
  
  2. const HtmlWebpackPlugin = require('html-webpack-plugin'); 
    3. 
  
  
  
  
  3.  
    4. 
  
  
  
  
  4. module.exports = { 
    5. 
  
  
  
  
  5.   mode: 'production', 
    6. 
  
  
  
  
  6.   entry: './src/main.js', 
    7. 
  
  
  
  
  7.   output: {...}, 
    8. 
  
  
  
  
  8.   devServer: { 
    9. 
  
  
  
  
  9.     port: '3000', 
    10. 
  
  
  
  
  10.     compress: true, 
    11. 
  
  
  
  
  11.     open: true, 
    12. 
  
  
  
  
  12.     hot: true, 
    13. 
  
  
  
  
  13.     proxy: { 
    14. 
  
  
  
  
  14.       '/': { 
    15. 
  
  
  
  
  15.         target: 'http://127.0.0.1:3001', 
    16. 
  
  
  
  
  16.         changeOrigin: true 
    17. 
  
  
  
  
  17.       } 
    18. 
  
  
  
  
  18.     } 
    19. 
  
  
  
  
  19.   }, 
    20. 
  
  
  
  
  20.   // 配置WEBPACK的插件 
    21. 
  
  
  
  
  21.   plugins: [ 
    22. 
  
  
  
  
  22.     new HtmlWebpackPlugin({ 
    23. 
  
  
  
  
  23.       template: `./public/index.html`, 
    24. 
  
  
  
  
  24.       filename: `index.html` 
    25. 
  
  
  
  
  25.     }) 
    26. 
  
  
  
  
  26.   ] 
    27. 
  
  
  
  
  27. }; 
    28.

图解Proxy的原理

Proxy代理其实相当于由webpack-dev-server配置在本地创建了一个port=3000的服务，利用node的中间层代理（分发）解决了浏览器的同源策略限制。

但是它只能在开发环境下使用，因为dev-server只是一个webpack的一个插件；

如果需要在生产环境下使用，需要我们配置Nginx反向代理服务器；

另外如果是自己实现node服务层代理：无论是开发环境还是生产环境都可以处理（node中间层和客户端是同源，中间层帮助我们向服务器请求数据，再把数据返回给客户端）

Proxy的局限性
只能在本地开发阶段使用

配置Nginx反向代理
主要作为生产环境下跨域的解决方案。

原理：利用Node中间层的分发机制，将请求的URL转向服务器端的地址

配置反向代理

 
 
 
 
    
  
  
  
  
  1. server { 
    2. 
  
  
  
  
  2.  listen: 80; 
    3. 
  
  
  
  
  3.   server_name: 192.168.161.189; 
    4. 
  
  
  
  
  4.   loaction: { 
    5. 
  
  
  
  
  5.   proxy_pass_http://127.0.0.1:1001; // 请求转向这个URL地址，服务器地址 
    6. 
  
  
  
  
  6.     root html; 
    7. 
  
  
  
  
  7.     index index.html; 
    8. 
  
  
  
  
  8.   } 
    9. 
  
  
  
  
  9. } 
    10.

简单写了一下伪代码，实际开发中根据需求来配。

POST MESSAGE
假设现在有两个页面，分别为A页面port=1001、B页面port=1002，实现页面A与页面B的页面通信（跨域）

原理：

把 B页面当做A的子页面嵌入到A页面里，通过iframe.contentWindow.postMessage向B页面传递某些信息
在A页面中通过window.onmessage获取A页面传递过来的信息ev.data(见下代码)
同理在B页面中通过ev.source.postMessage向A页面传递信息
在A页面中通过window.onmessage获取B页面传递的信息
主要利用内置的postMessage和onmessage传递信息和接收信息。

A.html

 
 
 
 
    
  
  
  
  
  1. // 把 B页面当做A的子页面嵌入到A页面里 
    2. 
  
  
  
  
  2.  
    3. 
  
  
  
  
  3.  
    4. 
  
  
  
  
  4.  
    5.

B.html

 
 
 
 
    
  
  
  
  
  1.  
    2.

几种方案的比较
1. JSONP方案需要前后端共同配置完成（利用script标签不存在域的限制）【麻烦，老项目使用】

2. CORS原理简单，但只能配置单一源，如果需要配置多个源，也只能从白名单中筛选出某一个符合表求的origin【偶尔使用】

服务器端需要单独做处理，客户端较为简单

3. Proxy客户端通过dev-server，生产环境需要配置Nginx反向代理（利用Node中间层分发机制）【常用】

本文名称：「深入浅出」前端开发中常用的几种跨域解决方案
本文URL：http://www.stwzsj.com/qtweb/news40/11140.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联

猜你还喜欢下面的内容

自适应网站知识

同城分类信息

重庆网站建设网络公司　　 　成都网站维护公司　　 　新型地坪材料　　 　成都网站建设　　 　高端网站设计　　 　木包装箱　　 　雅安托管服务器　　 　重庆服务器托管　　 　成都微信开发　　 　整合营销　　 　手机网站建设套餐　　 　禾巨建站　　 　绵竹网站建设　　 　成都模板网站　　 　边坡防护网　　 　成都小程序制作　　 　服务器托管　　 　南充主机托管　　 　重庆水土机房托管　　 　企业网站设计