跨域及三种常见解决方案

什么是跨域

跨域是浏览器受同源(协议、域名、端口)策略的限制,不允许不同源的站点之间进行某些操作(如发送ajax请求,操作dom,读取cookie),如果不进行特殊配置是不能操作成功的,并且控制台会报如下跨域错误:
No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'xxxxxx' is therefore not allowed access

跨域出现的场景

两个常见的例子:

  • 前后端分离的项目联调时,客户端和服务端ip不一致

    一般前端本地服务启动在localhost:8080上,服务端接口部署在联调服务器上,此时向联调服务器发送请求的话就会发生跨域

  • 大型项目中可能需要多个服务,不同职责的服务部署在不同的端口上,甚至多个服务器上

    在当前网站页面上请求其他服务器或者其他端口上的接口,也会发生跨域,这种情况一般通过nginx反向代理解决

跨域解决方案

JSONP

原理:利用script标签的src属性不受同源策略的限制,并且资源加载完成后会被当作js脚本立即执行的特点,来达到跨域请求资源的目的。

需要做一些特殊处理:准备一个callback函数用于处理后端传来的数据,将callback函数的名字作为src属性中的query传给后端,后端收到后用callback函数名将数据包裹起来,使数据作为参数返回给前端,当资源加载完成,callback会立即被调用,此时的实参就是我们需要的数据。

javascript 复制代码
var script = document.createElement('script');

// 传参一个回调函数名给后端,方便后端返回时执行这个在前端定义的回调函数
script.src = 'http://www.domain2.com:8080/login?user=admin&callback=handleCallback';
document.head.appendChild(script);

// 回调执行函数
function handleCallback(res) {
    alert(JSON.stringify(res));
}

服务端返回如下(返回时即执行全局函数):

json 复制代码
handleCallback({"success": true, "user": "admin"})

JSONP的优缺点:

  • 优点
    • 兼容性好,支持老的浏览器
  • 缺点
    • 只支持get请求,因为script标签请求资源本质就是一个get请求
    • 需要服务端专门配置,把数据用callback函数名包裹起来再返回

CORS

CORS是w3c指定的跨域方案,支持所有类型的请求;兼容性:ie不能低于ie 10

CORS跨域方案将所有请求划分为简单请求和非简单请求两类,对其分别采用不同的处理方案。

简单请求

同时满足以下两个条件的请求属于简单请求:

  • 请求方法是getposthead中的一种
  • http头字段不超出:
  • Accept
  • Accept-Language
  • Accept-Language
  • Content-Type仅限于text/plainmultipart/form-dataapplication/x-www-form-urlencoded

简单请求流程

浏览器在请求头中自动加入origin字段,origin字段用来说明本次请求来自哪个源(协议+域名+端口),服务器根据这个值,决定是否同意这次请求。

如果origin指定的源,不在许可范围内,服务器会返回一个正常的http回应。浏览器发现,这个回应的头信息没有包含 Access-Control-Allow-Origin 字段,就知道出错了,从而抛出一个错误,被XMLHttpRequestonerror回调函数捕获。注意,这种错误无法通过状态码识别,因为HTTP回应的状态码有可能是200。

如果Origin指定的域名在许可范围内,服务器返回的头字段中会包含Access-Control-Allow-Origin,它的值要么是请求时Origin字段的值,要么是一个*,表示接受任意域名的请求。

如何设置cookie?

  • cors请求默认不携带cookie,如果想要发送cookie,需要服务端和客户端同时设置
  • 一方面要服务器同意,指定Access-Control-Allow-Credentials: true
  • 另一方面,开发者必须在ajax请求中打开withCredentials属性。xhr.withCredentials = true;

非简单请求

预检请求

非简单请求需要先发出一个预检请求,预检请求方法是OPTIONS,用来获知服务器是否允许该实际请求。"预检请求"的使用,可以避免跨域请求对服务器的用户数据产生未预期的影响(PUT、delete)

请求头字段

  • Origin
  • Access-Control-Request-Method
  • Access-Control-Request-Headers

预检请求的回应

  • 如果允许跨源请求
    • Access-Control-Allow-Origin
    • Access-Control-Allow-Methods(返回的是所有支持的方法,而不单是浏览器请求的那个方法。这是为了避免多次"预检"请求。)
    • Access-Control-Allow-Headers(是一个逗号分隔的字符串,表明服务器支持的所有头信息字段,不限于浏览器在"预检"中请求的字段。)
    • Access-Control-Allow-Credentials
      • 如何设置cookie?
        • cors请求默认不发送cookie,如果想要发送cookie,需要服务端和客户端同时设置
        • 一方面要服务器同意,指定Access-Control-Allow-Credentials: true
        • 另一方面,开发者必须在AJAX请求中打开withCredentials属性。
    • Access-Control-Max-Age
      • 该字段可选,用来指定本次预检请求的有效期,单位为秒。在此期间,不用发出另一条预检请求。
  • 如果不允许,比如origin不在信任名单内
    • 会返回一个正常的HTTP回应,但是没有任何CORS相关的头信息字段。浏览器就会报错

正常请求

一旦服务器通过了"预检"请求,以后每次浏览器正常的CORS请求,就都跟简单请求一样,会有一个Origin头信息字段。服务器的回应,也都会有一个Access-Control-Allow-Origin头信息字段。

反向代理

跨域是浏览器的保护机制,如果绕过浏览器,使用代理服务器去请求目标服务器上的数据,就不会受跨域影响。因此前端可以通过脚手架或webpack配置devSever下的proxy选项,将/api开头的请求转发到真实服务器上。

在生产环境下也可以使用nginx配置反向代理来解决跨域。

相关推荐
hong_zc16 分钟前
初始 html
前端·html
小小吱21 分钟前
HTML动画
前端·html
Xiao Fei Xiangζั͡ޓއއ26 分钟前
一觉睡醒,全世界计算机水平下降100倍,而我却精通C语言——scanf函数
c语言·开发语言·笔记·程序人生·面试·蓝桥杯·学习方法
Bio Coder38 分钟前
学习用 Javascript、HTML、CSS 以及 Node.js 开发一个 uTools 插件,学习计划及其周期
javascript·学习·html·开发·utools
糊涂涂是个小盆友43 分钟前
前端 - 使用uniapp+vue搭建前端项目(app端)
前端·vue.js·uni-app
NMBG221 小时前
[JAVAEE] 面试题(四) - 多线程下使用ArrayList涉及到的线程安全问题及解决
java·开发语言·面试·java-ee·intellij-idea
浮华似水1 小时前
Javascirpt时区——脱坑指南
前端
王二端茶倒水1 小时前
大龄程序员兼职跑外卖第五周之亲身感悟
前端·后端·程序员
_oP_i1 小时前
Web 与 Unity 之间的交互
前端·unity·交互
钢铁小狗侠1 小时前
前端(1)——快速入门HTML
前端·html