跨域，一个陈词滥调的问题，也是前后端交互必然也常常会碰到的问题，置信大家都不生疏，尽管不是什么浅近的货色，然而脚手架的层层封装，各种 API 的层出不穷，未免有些应接不暇，所以这种状况，就只有本人总结一下了，如果你对它并不是那么相熟，置信对必定会对你有帮忙的

说跨域之前，首先须要理解的一个概念是同源策略

因为浏览器有安全策略限度，不同源的地址之间不能相互拜访资源或者操作DOM

对于同源策略不理解的能够看我另一篇文章有具体介绍：
吃透浏览器平安（同源限度/XSS/CSRF/中间人攻打）

跨域有哪些计划？

这里只介绍几种开发中用的比拟多的，简直用不到的比方：

  • document.domain + iframe：实用主域名雷同，子域名不同的跨域场景
  • window.name + iframe：利用name值最长能够 2M ，并用不同页面或不同域名加载后仍然存在的个性
  • location.hash + iframe：实用通过 C 页面来实现 A 页面与 B 页面通信的场景

就不过多开展了

1. CORS

面试爱问这个

CORS 通信过程都是浏览器主动实现，须要浏览器(都反对)和服务器都反对，所以要害在只有服务器反对，就能够跨域通信，CORS申请分两类，简略申请和非简略申请

另外CORS申请默认不蕴含Cookie以及HTTP认证信息，如果须要蕴含Cookie，须要满足几个条件：

  • 服务器指定了 Access-Control-Allow-Credentials: true
  • 开发者须在申请中关上withCredentials属性: xhr.withCredentials = true
  • Access-Control-Allow-Origin不要设为星号，指定明确的与申请网页统一的域名，这样就不会把其余域名的Cookie上传

简略申请

须要同时满足两个条件，就属于简略申请：

  • 申请办法是：HEAD、GET、POST，三者之一

  • 申请头信息不超过以下几个字段：

    • Accept
    • Accept-Language
    • Content-Language
    • Last-Event-Id
    • Content-Type：值为三者之一application/x-www/form/urlencoded、multipart/form-data、text/plain

须要这些条件是为了兼容表单，因为历史上表单始终能够跨域

浏览器间接收回CORS申请，具体来说就是在头信息中减少Origin字段，示意申请起源来自哪个域(协定+域名+端口)，服务器依据这个值决定是否批准申请。如果批准，返回的响应会多出以下响应头信息

Access-Control-Allow-Origin: http://juejin.com // 和 Orign 统一  这个字段是必须的Access-Control-Allow-Credentials: true // 示意是否容许发送 Cookie  这个字段是可选的Access-Control-Expose-Headers: FooBar // 指定返回其余字段的值   这个字段是可选的Content-Type: text/html; charset=utf-8 // 示意文档类型

在简略申请中服务器至多须要设置：Access-Control-Allow-Origin 字段

非简略申请

比方 PUT 或 DELETE 申请，或 Content-Type 为 application/json ，就是非简略申请。

非简略 CORS 申请，正式申请前会发一次 OPTIONS 类型的查问申请，称为预检申请，询问服务器是否反对网页所在域名的申请，以及能够应用哪些头信息字段。只有收到必定的回答，才会发动正式XMLHttpRequest申请，否则报错

预检申请的办法是OPTIONS，它的头信息中有几个字段

  • Origin: 示意申请来自哪个域，这个字段是必须的
  • Access-Control-Request-Method：列出CORS申请会用到哪些HTTP办法，这个字段是必须的
  • Access-Control-Request-Headers： 指定CORS申请会额定发送的头信息字段，用逗号隔开

OPTIONS申请次数过多也会损耗性能，所以要尽量减少OPTIONS申请，能够让服务器在申请返回头部增加

Access-Control-Max-Age: Number // 数字 单位是秒

示意预检申请的返回后果能够被缓存多久，在这个工夫范畴内再申请就不须要预检了。不过这个缓存只对齐全一样的URL才会失效

2. Nginx代理跨域

配置一个代理服务器向服务器申请，再将数据返回给客户端，本质和CORS跨域原理一样，须要配置申请响应头Access-Control-Allow-Origin等字段，正向代理和反向代理看我另一篇http的文章有介绍

server {     listen 81; server_name www.domain1.com;     location / {         proxy_pass http://xxxx1:8080; // 反向代理         proxy_cookie_domain www.xxxx1.com www.xxxx2.com; // 批改cookie里域名         index index.html index.htm;         // 当用webpack-dev-server等中间件代理接口拜访nignx时，此时无浏览器参加，故没有同源限度，上面的跨域配置可不启用         add_header Access-Control-Allow-Origin http://www.xxxx2.com; // 以后端只跨域不带cookie时，可为*         add_header Access-Control-Allow-Credentials true;     } }

3. Node中间件代理跨域

在 Vue 中 vue.config.js 中配置

module.export = {    ...    devServer: {        proxy: {            [ process.env.VUE_APP_BASE_API ]: {                target: 'http://xxxx',//代理跨域指标接口                ws: true,                changeOrigin: true,                pathRewrite: {                    [ '^' + process.env.VUE_APP_BASE_API ] : ''                }            }        }    }}

Node + express

const express = require('express')const proxy = require('http-proxy-middleware')const app = express()app.use('/', proxy({     // 代理跨域指标接口     target: 'http://xxxx:8080',     changeOrigin: true,     // 批改响应头信息，实现跨域并容许带cookie     onProxyRes: function(proxyRes, req, res) {         res.header('Access-Control-Allow-Origin', 'http://xxxx')        res.header('Access-Control-Allow-Credentials', 'true')    },     // 批改响应信息中的cookie域名     cookieDomainRewrite: 'www.domain1.com' // 能够为false，示意不批改})); app.listen(3000);

4. WebSocket

WebSocket是HTML5规范中的一种通信协议，以ws://(非加密)和wss://(加密)作为协定前缀，该协定不履行同源政策，只有服务器反对就行

因为WebSocket申请头信息中有Origin字段，示意申请源来自哪个域，服务器能够依据这个字段判断是否容许本次通信，如果在白名单内，就能够通信

// 应用 socket.io 插件<script src="https://cdn.bootcss.com/socket.io/2.2.0/socket.io.js"></script> <script>     const socket = io('http://xxxx:8080'); // 连贯胜利解决     socket.on('connect', function() {         // 监听服务端音讯         socket.on('message', function(msg) {             console.log('新音讯' + msg);         });         // 监听服务端敞开         socket.on('disconnect', function() {             console.log('连贯敞开');         })    })</script>

5. postMessage

postMessage是HTML5规范中的API，它能够给咱们解决如下问题：

  • 页面和新关上的窗口间数据传递
  • 多窗口之间数据传递
  • 页面与嵌套的 iframe 之间数据传递
  • 下面三个场景之间的跨域传递

postMessage 承受两个参数，用法如下：

  • 参数一：发送的数据
  • 参数二：你要发送给谁就写谁的地址(协定 + 域名 +端口)，也能够设置为*，示意任意窗口，为/示意与以后窗口同源的窗口
// 发送方 window.parent.pastMessage('发送的数据','http://接管的址')

如果是向 iframe 发送的话

// 发送方 <iframe id="iframe" src="http://xxxx"></iframe><script>    const iframe = document.getElementById('iframe')    iframe.onload = () => {        iframe.contentWindow.pastMessage('发送的数据','http://接管的址')     }</script>window.parent.pastMessage('发送的数据','http://接管的址') 
// 接管方 window.addEventListener('message',(e)=>{    console.log('接管到的数据：' + e.data})

6. JSONP

原理就是通过增加一个<script>标签，向服务器申请JSON数据，这样不受同源政策限度。服务器收到申请后，将数据放在一个callback回调函数中传回来。比方axios。

不过只反对GET申请且不平安，可能遇到XSS攻打，不过它的益处是能够向老浏览器或不反对CORS的网站申请数据

<script>    let script = document.createElement('script')    script.type = 'text/javascript'    script.src = 'http://juejin.com/xxx?callback=handleCallback'    document.body.appendChild(script)        function handleCallback(res){        console.log(res)    }</script>

服务器返回并立刻执行

handleCallback({ code: 200, msg: 'success', data: [] })

跨域时 Cookie 要做何解决？

指的就是对第三方应用 Cookie 的设置，在 Cookie 信息中增加 SameSite 属性

Set-Cookie: widget_session=123456; SameSite=None; Secure

SameSite 有三个值：

  • strict：严格模式，齐全禁止应用Cookie
  • lax：宽松模式，容许局部状况应用Cookie，跨域的都行，a标签跳转，link标签，GET提交的表单
  • none：任何状况下都会发送Cookie，但必须同时设置Secure属性，意思是须要平安上下文，Cookie 只能通过https发送，否则有效

Chrome 80之前默认值是none，之后是lax

不过在最新的 Chrome91 版本中这个曾经被移除了，所以在 91之前的版本仍然能够应用

如果 Chrome 或 Edge 版本大于91小于94的话，能够通过Chromium反对的command-line flag

  • 右键 Chrome 或 Edge 浏览器，抉择属性
  • 在指标(Target)属性开端加上
 --disable-features=SameSiteByDefaultCookies,CookiesWithoutSameSiteMustBeSecure

并且官网说的到 94 版本会连 comman-line 也会移除

官网的说法是任由开发者管制这两个选项，容易被攻打

结语

我感觉能不跨域的话还是还是尽量放弃同域好，开发用下前端的代理，部署用Nginx代理一下。或者在申请中设置跨域头，原理都是一样的，就是响应头设置跨域参数而已

点赞反对、手留余香、与有荣焉