1. 同源策略和跨域

1.1 什么是同源

如果两个页面的协议、域名和端口都相同，则说明两个页面具有相同的源。比如下面的图片，给出了相对于http://www.test.com/index.html页面的同源监测：

image.png

1.2 什么是同源策略

同源策略（Same origin policy）是一种约定，它是浏览器最核心也是最基本的安全功能，如果缺少了同源策略，则浏览器的正常功能可能都会收到影响。可以说Web是构建在同源策略基础之上的，浏览器只是针对同源策略的一种实现。

它的核心就在于它认为从任何站点装载的信息内容都是不安全的，它们应该只被允许访问来自同一站点的资源，而不是那些来自其它站点可能怀有恶意的资源。

另外，同源策略分为以下两种：

DOM同源策略：
禁止对不同源页面DOM进行操作。这里主要场景是iframe跨域的情况，不同域名的iframe是限制互相访问的；
XMLHttpRequest同源策略：
禁止使用XHR对象向不同源的服务器地址发起HTTP请求；

1.3 为什么要有跨域限制

因为存在浏览器同源策略，所以才会有跨域问题。那么浏览器是出于何种原因会有跨域的限制呢？其实很简单，就是为了用户的上网安全。

1.3.1 如果没有DOM同源策略

如果没有DOM同源策略，也就是说不同域的iframe之间可以相互访问，那么黑客可以这样进行攻击：

做一个假网站，里面用iframe嵌套一个银行网站：http://testbank.com
把iframe宽高调整到页面全部，这样用户进来之后除了域名，别的部分和银行的网站没有任何区别；
如果用户输入账号密码，我们的主网站可以跨域访问到http://testbank.com的dom节点，就可以拿到用户的账户密码了；

1.3.2 如果没有XMLHttpRequest同源策略

如果没有XMLHttpRequest同源策略，那么黑客可以进行CSRF（跨站请求伪造）攻击：

用户登录了自己的银行页面http://testbank.com，向用户的cookie中添加用户标识；
用户浏览了恶意页面 http://evil.com，执行了页面中的AJAX请求代码；
请求中会默认携带cookie；
银行页面从发送的cookie中提取用户标识，验证用户无误，response中返回请求数据，此时数据就泄露了。由于Ajax在后台执行，用户无法感知这一过程；

因此，有了浏览器的同源策略，才能让我们更安全的上网。

1.3.3 跨域

从上面我们了解到了浏览器同源策略的作用，也正是有了跨域限制，才使我们能安全的上网。但是在实际开发中，我们需要突破这样的限制。

出现跨域的根本原因是：浏览器的同源策略不允许非同源的URL之间进行资源的交互。

比如：
当前的网页是：http://www.test.com/index.html
请求的接口是：http:www.api.com/userlist

下图中展示的是浏览器对跨域请求的拦截：

image.png

从上图中我们可以看到，浏览器是允许发起请求，但是，跨域请求回来的数据，会被浏览器拦截，无法被页面获取到。

2. 如何实现跨域请求

实现跨域数据请求方法有很多，比如JSONP、CORS、使用Proxy等。

JSONP：
出现的早，兼容性好（兼容低版本IE）。是前端程序员为了解决跨域问题，被迫想出来的一种临时解决方案。缺点是只支持 GET 请求，不支持 POST 请求；
CORS:
出现的较晚，它是 W3C 标准，属于跨域 AJAX 请求的根本解决方案。支持 GET 和 POST 请求。缺点是不兼容某些低版本的浏览器。
Proxy:
既然跨域是浏览器导致的，那我们可以使用代理绕开浏览器，这也是常见的解决跨域的方案；

3. JSONP

JSONP(JSON with Padding)是JSON的一种使用模式，可用于解决主流浏览器跨域数据访问的问题。

3.1 JSONP原理

由于script标签不受浏览器同源策略的影响，允许跨域引用资源。因此，可以通过动态创建script标签，然后利用src属性进行跨域。

事先定义一个用于获取跨域响应数据的回调函数；
创建一个script标签发起一个请求（将回调函数的名称作为参数放到这个请求的query参数里）；
服务端获取到这个请求之后，获取query中的回调函数的名称，并将数据放到回调函数的参数里，作为请求的响应；
前端的script标签收到请求的响应之后，会立马执行这个回调函数，于是，就可以在之前定义的回调函数中获取到数据了；

3.2 示例

3.2.1 前端请求示例

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Document</title>
</head>
<body>
    <script>
        // 1.定义一个回调函数，用来接收返回的数据
        function getData(data) {
            console.log('data :>> ', data);
        }
    </script>
        <!-- 2.使用script标签(也可以动态创建)，并且告诉后端回调函数的名字是getData -->
        <!-- 3.通过script.src 请求 http://localhost:8080/api/data?cb=getData-->
        <!-- 4.后端识别这样的url格式并处理该请求，然后返回 getData('hello') 给浏览器 -->
        <!-- 5.浏览器在接收到 getData('hello') 数据之后，会执行 getData 方法，获得后端返回的数据 -->
    <script src="http://localhost:8080/api/data?cb=getData"></script>
</body>
</html>

3.2.2 后端响应示例

const http = require('http')
const url = require('url')

const server = http.createServer((req, res)=>{
    let urlString = req.url
    let urlObj = url.parse(urlString, true)
    res.write(`${urlObj.query.cb}("hello")`)
    res.end()
})
server.listen(8080, () => {
    console.log("localhost:8080");
})

3.3 优/缺点

优点：

使用简单，没有兼容性问题；
请求完毕之后可以通过调用callback的方式回传结果；

缺点：

只支持GET请求，不支持POST等其它类型的请求；
由于是从其它域中加载代码执行，因此如果其他域不安全，很可能会在响应中夹带一些恶意代码；
只支持HTTP请求这种情况，不能解决不同域的两个页面之间如何进行JavaScript调用的问题；
要确定JSONP请求是否失败并不容易，虽然H5给script标签新增了一个onerror事件处理程序，但是存在兼容性问题；

4.CORS

之前在学习OPTIONS预检请求的时候，已经总结过了。详见：//www.greatytc.com/p/d9d30dc9898b

5. Proxy

简单来说，就是请求自己同源的服务（代理），然后通过代理去请求跨域的资源。常用的解决方案一般是两种：本地代理和nginx反向代理。

5.1 本地代理

开发环境，前端处理。

无论是 webpack 还是 vite 都内置了本地代理。这让我们能够在不依赖后端的前提下解决跨域的问题(仅仅是本地开发环境下, 线上环境需要 nginx 配置反向代理)

webpack的处理方式如下：

module.exports = {
  //...
  devServer: {
    proxy: {
      '/api': 'http://localhost:3000'
    }
  }
};

vite的处理方式：

export default defineConfig({
  // ...
  server: {
    proxy: {
      '/api': {
        target: 'http://jsonplaceholder.typicode.com',
        changeOrigin: true,
        rewrite: (path) => path.replace(/^\/api/, '')
      }
    }
  }
});

5.2 nginx反向代理

生产环境一般用 nginx 托管部署我们的前端代码包。处理跨域问题需要 nginx 配置反向代理。

server {
    listen: 8001;
    server_name 10.2.2.25;

    location ~ /api/ {
        proxy_pass http://127.0.0.1:8081;
    }
}

【前端Tip】同源策略以及实现跨域请求