浏览器跨域

一个域下的JS脚本在未经允许的情况下，不能访问另一个域的内容，同源指的是协议域名和端口均相等的情况为同一个域。

跨域

由于同源策略的限制，请求发送到后端，后端返回数据时被浏览器的跨域报错拦截。
问：跨域的请求在服务端会不会真正执行？
服务端就算是想拦截，也没法判断请求是否跨域，HTTP Request的所有Header都是可以被篡改的，它用什么去判断请求是否跨域呢？很明显服务端心有余而力不足啊！
options:预检请求有一个很重要的作用就是询问服务端是不是允许这次请求，如果当前请求是个跨域的请求，你可以理解为：询问服务端是不是允许请求在当前域下跨域发送。
当然，它还有其他的作用，比如询问服务端支持哪些HTTP方法。
预检请求虽然不会真正在服务端执行逻辑，但也是一个请求啊，考虑到服务端的开销，不是所有请求都会发送预检的。
一旦浏览器把请求判定为简单请求，浏览器就不会发送预检了。
所以，如果你发送的是一个简单请求，这个请求不管是不是会受到跨域的限制，只要发出去了，一定会在服务端被执行，浏览器只是隐藏了返回值而已。
对于前端开发而言，大部分的跨域问题，都是通过代理解决的。
代理使用的场景是：生产环境不发生跨域，但开发环境发生跨域。所以，只需要在开发环境使用代理解决跨域即可一开发代理。

服务器与服务器通信不受跨域的影响，解决跨域也就可以从这个角度入手。

浏览器不允许跨域的原因？

防止黑客入侵

为啥html标签可以跨域？

html标签只能调用get方法

在有服务器权限的情况下

1. 服务器配置CROS实现跨域
   跨域资源共享Cross Origin Resourse-Sharing
   一般后端开启。是基于HTTP1.1的一种跨域解决方案。
   服务端设置Access-Control-Allow-Origin就可以开启CORS。该属性表示哪些域名可以访问资源，如果设置通配符则表示所有网站都可以访问资源。
   一个请求可以附带很多信息，会对服务器造成不同程度的影响，有的请求只是获取一些新闻，有的请求会改动服务器的数据。
   针对不同的请求，CORS规定了3种不同的交互模式

• 简单请求

• 需要预检的请求

• 附带身份凭证的请求

  • 简单请求
    当请求同时满足以下条件时，浏览器会认为它是一个简单请求：
    1.请求方法属于下面的一种：
    get
    post
    head
    2.请求头仅包含安全的字段，常见的安全字段如下：
    Accept
    Accept-Language
    Content-Language
    Content-Type
    DPR
    Downlink
    Save-Data
    Viewport-Width
    Width
    3.请求头如果包含Content-Type,仅限下面的值之一：
    text/plain
    multipart/form-data
    application/x-www-form-urlencoded
    4.请求中的任意XMLHttpRequest对象均没有注册任何事件监听器；MLHttpRequest对象可以使用
    MLHttpRequest.upload属性访问。
    5.请求中没有使用ReadableStream对象。
    如果以上条件同时满足，浏览器判定为简单请求。
    当浏览器判定某个ajax跨域请求是简单请求时，会发生以下的事情
    1.请求头中会自动添加Origin字段
    比如，在页面http://my.com/index.html中有以下代码造成了跨域
    //简单请求
    fetch(‘http://crossdomain.com/api/news‘);
    请求发出后，请求头会是下面的格式：
    GET /api/news/HTTP/1.1
    Host:crossdomain.com
    Connection:keep-alive

    1 2	Referer:http://my.com/index.html Origin:http://my.com

    最后一行，Origin字段会告诉服务器，是哪个源地址在跨域请求
    2.服务器响应头中应包含Access-Control-Allow-Origin
    当服务器收到请求后，如果允许该请求跨域访问，需要在响应头中添加Access-.Control-Allow-Origin字段
    该字段的值可以是：
  • *：表示我很开放，什么人我都允许访问
  • 具体的源：比如http://my.com,表示我就允许你访问

    实际上，这两个值对于客户端http://y.com而言，都一样，因为客户端才不会管其他源服务器允不允许，就关心自己是否被允许

  假设服务器做出了以下的响应：
  HTTP/1.1 200OK

  1	Access-Control-Allow-0rigin:http://my.com

  消息体中的数据
  当浏览器看到服务器允许自己访问后，高兴的像一个两百斤的孩子，于是，它就把响应顺利的交给js,以完成后续
  的操作
  需要预检请求
  但是，如果浏览器不认为这是一种简单请求，就会按照下面的流程进行
  1.浏览器发送预检请求，询问服务器是否允许
  2.服务器允许
  3.浏览器发送真实请求
  4.服务器完成真实的响应

比如，在页面http://my.com/index.html中有以下代码造成了跨域

1
2
3
4
5
6
7
8
9
10
11
12
13
14

//需要预检的请求
fetch('http://crossdomain.com/api/user',
method:'P0ST',//post请求
headers:
//设置请求头
a:1,
b:2,
'content-type':'application/json',
},
body:JSON.stringify({
name:'袁小进'，
age:18
}),//设置请求体
})

浏览器发现它不是一个简单请求，则会按照下面的流程与服务器交互
1.浏览器发送预检请求，询问服务器是否允许
OPTIONS /api/user HTTP/1.1
Host:crossdomain.com

1
2
3

origin:http://my.com
Access-Control-Request-Method:POST
Access-Control-Request-Headers:a,b,content-type

可以看出，这并非我们想要发出的真实请求，请求中不包含我们的请求头，也没有消息体。
这是一个预检请求，它的目的是询问服务器，是否允许后续的真实请求。
预检请求没有请求体，它包含了后续真实请求要做的事情
预检请求有以下特征：

• 请求方法为OPTIONS
• 没有请求体
• 请求头中包含
• Origin:请求的源，和简单请求的含义一致
• Access-Control–Request-Method:后续的真实请求将使用的请求方法
• Access–Control-Request-Headers:后续的真实请求会改动的请求头

2.服务器允许
服务器收到预检请求后，可以检查预检请求中包含的信息，如果允许这样的请求，需要响应下面的消息格式
HTTP/1.1 200OK
Date:Tue,21 Apr 2020 08:03:35 GMT

1
2
3
4

Access-Control-Allow-origin:http://my.com
Access-Control-ALlow-Methods:POST
Access-Control-Allow-Headers:a,b,content-type
Access-Control-Max-Age:86400

对于预检请求，不需要响应任何的消息体，只需要在响应头中添加：

• Access–Control-Allow-Origin:和简单请求一样，表示允许的源
• Access-Control-Allow-Methods:表示允许的后续真实的请求方法
• Access-Control-Allow-Headers:表示允许改动的请求头
• Access-Control-Max-Age:告诉浏览器，多少秒内，对于同样的请求源、方法、头，都不需要再发送预检请求了
  3.浏览器发送真实请求
  预检被服务器允许后，浏览器就会发送真实请求了，上面的代码会发生下面的请求数据
  POST /api/user HTTP/1.1
  Host:crossdomain.com
  Connection:keep-alive

  1 2 3

  Referer:http://my.com/index.html Origin:http://my.com {"name":"xiaoming","age":18}

  4服务器响应真实请求
  HTTP/1.1 200OK
  Date:Tue,21 Apr 2020 08:03:35 GMT

  1	Access-Control-Allow-origin:http://my.com

  添加用户成功
  可以看出，当完成预检之后，后续的处理与简单请求相同
  附带身份凭证请求
  默认情况下，ajax的跨域请求并不会附带cookie,这样一来，某些需要权限的操作就无法进行
  不过可以通过简单的配置就可以实现附带cookie

  1 2 3 4 5 6 7

  //xhr var xhr new XMLHttpRequest(); xhr.withCredentials true; //fetch api fetch(url, credentials:include', }):

  当一个请求需要附带cookie时，无论它是简单请求，还是预检请求，都会在请求头中添加cookie字段
  而服务器响应时，需要明确告知客户端：服务器允许这样的凭据
  告知的方式也非常的简单，只需要在响应头中添加：Access-Control-Allow-Credentials:true即可
  对于一个附带身份凭证的请求，若服务器没有明确告知，浏览器仍然视为跨域被拒绝。
  另外要特别注意的是：对于附带身份凭证的请求，服务器不得设置Access-Contro-Allow-Origin的值为*。这就是
  不推荐使用的原因

  额外补充

在跨域访问时，JS只能拿到一些最基本的响应头，如：Cache-Control、Content-Language、Content–Type、
Expires、Last-Modified、Pragma,如果要访问其他头，则需要服务器设置本响应头。
Access-Control-Expose-Headers:头让服务器把允许浏览器访问的头放入白名单，例如：
Access-Control-Expose-Headers:authorization,a,b
这样JS就能够访问指定的响应头了。
代理
适用场景：生产环境不发生跨域，但开发环境发生跨域。
开发代理：只需要在开发环境使用代理解决跨域。

1
2
3
4
5

module.exports =
devServer:{//配置开发服务器
proxy:{//配置代理
"/api":{//若请求路径以/api开头
target:"http://dev.taobao.com",//将其转发到http://dev.taobao.com

nginx代理
反向代理功能是nginx的三大主要功能之一（静态wb服务器、反向代理、负载均衡）。
反向代理：帮服务器拿到数据，然后选择合适的服务器。
和CORS原理同，需要配置请求响应头Access-Control-Alow-Origin等字段。
怎么做反向代理与负载均衡
Ngx作为反向代理服务器，就是把http请求转发到另一个或者一些服务器上。通过把本地一个url前缀映射到要跨
域访问的web服务器上，就可以实现跨域访问。
对于浏览器来说，访问的就是同源服务器上的一个ul。
而Nginxi通过检测url前缀，把http请求转发到后面真实的物理服务器。
并通过rewrite命令把前缀再去掉。这样真实的服务器就可以正确处理请求，并且并不知道这个请求是来自代理服务
器的。

正向代理就是冒充客户端，反向代理就是冒充服务端。

WebSocket协议（与HTTP同级）
因为WebSocketi请求头信息中有origin字段，表示请求源自哪个域，服务器可以根据这个字段判断是否允许本次通
信。
document.domain+iframe
原理：相同主域名不同子域名下的页面，
该方式只能用于二级域名相同的情况下，比如a.test.com和b.test.com适用于该方式。
只需要给页面添加document..domain=’test.com’表示二级域名都相同就可以实现跨域
location.hash iframe
通过C页面实现A和B通信
window.name(共享变量)+iframe
使用Apache做转发
逆向代理，让跨域变成同域。
2. JSONP（利用script标签和后端配合）
前后端配合。只支持GET方法且不安全。利用src发送请求，传递一个回调。
不受跨域问题限制：script,link,img,href,src,因为这些操作都不会通过响应结果进行可能出现安全问题的操
作。
通过标签指向一个需要访问的地址并提供一个回调函数来接收数据。

1
2
3
4
5
6
7
8
9
10
11

//去创建一个script标签
var script = document.createElement("script");
//script的src属性设置接口地址并带一个callback回调函数名称
script.src ="http://127.0.0.1:8888/index.php?callback=jsonpCallback";
//插入到页面
document.head.appendchild(script);
//通过定义函数名去接收后台返回数据
function jsonpCallback(data){
//注意jsonp返回的数据是json对象可以直接使用
//ajax取得数据是json字符串需要转换成json对象才可以使用。
}

3. 设置本地代理服务器
4. Nginx代理