当前位置: 首页 > news >正文

网络开发的隐形壁垒:如何巧妙解决跨域难题?

什么是跨域

跨域是浏览器受同源(协议、域名、端口)策略的限制,不允许不同源的站点之间进行某些操作(如发送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会立即被调用,此时的实参就是我们需要的数据。

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));
}

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

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配置反向代理来解决跨域。

学习资料:点此下载

http://www.lryc.cn/news/293066.html

相关文章:

  • 【极简】conda同一个服务器上迁移环境 export / create
  • HBase 数据导入导出
  • (java版)排序算法----【冒泡,选择,插入,希尔,快速排序,归并排序,基数排序】超详细~~
  • 服务器托管的作用是什么?
  • 美团启动架构调整:聚力核心本地商业,提升科技与境外业务优先级
  • 监测Tomcat项目宕机重启脚本(Linux)
  • 道可云元宇宙每日资讯|北京:推进元宇宙在智慧城市应用
  • Logback学习
  • 【Chrono Engine学习总结】2-可视化
  • pytorch创建tensor
  • Cmake语法学习3:语法
  • JavaScript 基础 - 第1天
  • 人口增长问题 T1063
  • 2024年Java算法面试题
  • C#——三角形面积公式
  • tcpdump在手机上的使用
  • unity 导出H5
  • 认识 SYN Flood 攻击
  • Node需要了解的知识
  • 网络服务综合实验项目
  • 工厂模式与抽象工厂模式
  • Springboot整合Websocket实现ws和wss连接
  • CSC联合培养博士申请亲历|联系外导的详细过程
  • 没有外网Nginx如何配置如何开启https
  • 【Docker篇】Linux安装Docker、docker安装mysql、redis、rabbitmq
  • WPF应用程序(.Net Framework 4.8) 国际化
  • Elasticsearch:Geoshape query
  • 安装配置sqoop
  • 数据结构——实验01-线性表的链式存储和操作
  • 十分钟上手vue!