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

LiteHub中间件之跨域访问CORS

跨域访问CORS

    • 原理
      • 基本概念
      • 简单请求
      • 非简单请求(预检请求)
    • 代码实现
      • 服务器端Cors的关键配置
      • 服务端解析预检请求
      • 服务端填充响应
    • 抓包分析

原理

基本概念

在浏览器安全模型中,同源策略是最重要的安全基石。
一个“域”是由3个要素组成的:

  • 协议(如:http 或 https)
  • 主机(Host,如 www.example.com 或 127.0.0.1)
  • 端口(Port,如 80 或 8080)

只要这三个完全一致,就是同源的。
例如

  • http://example.com:80 和 http://example.com:8080 是不同源
  • http://example.com 和 https://example.com 是不同源

下面是官网解释跨域的图解:
在这里插入图片描述

两种请求:浏览器将 CORS 请求分成两类:简单请求(simple request)和非简单请求(not-so-simple request)。

简单请求

按照 W3C 的 CORS 规范,只有完全满足「安全要求」的跨域请求,浏览器才会把它直接当成简单请求,直接发送给服务端,不需要先发 OPTIONS。
必须同时满足以下条件

  1. 请求方法必须是(GET/HEAD/POST)三者之一
  2. 请求头不能超出以下几个字段(Accept、Accept-Language、Content-Language、Content-Type)等
  3. Content-Type(如果存在的话),其值只能是application/x-www-form-urlencoded、multipart/form-data、text/plain

非简单请求(预检请求)

非简单请求是指那些对服务器有特殊要求的请求,例如:

  • 使用PUT或DELETE方法
  • 设置Content-Type为application/json
    即不满足简单请求的条件的都是预检请求(非简单请求)。

对于这类请求,浏览器会在正式通信前额外发送一次HTTP查询请求(即预检请求),这个过程叫做预检(Preflight)。该请求会确认:

  1. 当前网页域名是否在服务器的许可名单中
  2. 允许使用的HTTP方法和头信息字段
    只有在获得服务器肯定答复后,浏览器才会发出正式的XMLHttpRequest请求,否则将报错。

“预检请求”用的请求方法是 OPTIONS,表示这个请求是用来询问的。头信息里面,关键字是 Origin,表示请求来自哪个源。
除了 Origin 字段,“预检请求”的头信息包括两个特殊字段。
Access-Control-Request-Method:必须字段,列出浏览器的 CORS 请求会用到哪些 HTTP 方法;
Access-Control-Request-Headers:这个字段是一个逗号 , 分隔的字符串,指定浏览器 CORS 请求会额外发送的头信息字段,上面示例是 X-Custom-Header。

代码实现

CORS(Cross-Origin Resource Sharing,跨域资源共享)通过在响应头里加上一组特殊字段来告诉浏览器,这个资源允许被某些源访问。

服务器端Cors的关键配置

struct CorsConfig 
{std::vector<std::string> allowedOrigins;//允许哪些域名可以访问std::vector<std::string> allowedMethods; //允许哪些方法可以跨域调用std::vector<std::string> allowedHeaders; //允许前端请求里带哪些请求头bool allowCredentials = false; //不允许携带Cookie/Authorization header/TLS client cert 这类凭证信息int maxAge = 3600;             //浏览器缓存预检请求的最大时长, 1 小时内同样的跨域请求只会发送一次 OPTIONS,之后直接用缓存的结果static CorsConfig defaultConfig() {CorsConfig config;config.allowedOrigins = {"*"}; //这里允许的是所有域名config.allowedMethods = {"GET", "POST", "PUT", "DELETE", "OPTIONS"}; //在预检请求(OPTIONS)的响应里告诉浏览器:后端接受哪些方法config.allowedHeaders = {"Content-Type", "Authorization"}; //允许前端带Content-Type(比如 application/json)和Authorization(携带JWT Token等)return config;}
};

服务端解析预检请求

处理客户端发来的请求的流程如下:

  1. 判断是否是预检请求,如果是,进入下一步;否则不做处理(正常的请求,继续后续的处理流程,响应)
  2. 检查当前请求的源是否被允许,如果允许当前请求源则在响应头中添加该源字段,状态码为204 No content,响应体为空,进入下一步
  3. 直接抛出特殊的响应对象(中断后续的处理流程)

总结:如果是预检请求,设置Cors的相关字段,直接返回;否则就进入正常的处理流程。

/***  @brief 请求前钩子,所有请求进来时都会先执行* 如果是跨域的 OPTIONS 预检请求,直接构造响应并抛出,跳过后续中间件/路由逻辑。*/
void CorsMiddleware::before(HttpRequest& request) 
{LOG_DEBUG << "CorsMiddleware::before - Processing request";// 如果是浏览器发起的预检请求(CORS Preflight)if (request.method() == HttpRequest::Method::kOptions) {LOG_INFO << "Processing CORS preflight request";HttpResponse response;  // 创建预检响应handlePreflightRequest(request, response);// 直接中断后续处理流程,抛出特殊的响应对象throw response;}
}/*** @brief 处理 CORS 预检请求(OPTIONS)* 会校验 Origin,并返回允许的跨域头*/
void CorsMiddleware::handlePreflightRequest(const HttpRequest& request, HttpResponse& response) 
{   // 从请求头获取 Originconst std::string& origin = request.getHeader("Origin");// 校验是否允许跨域if (!isOriginAllowed(origin)) {LOG_WARN << "Origin not allowed: " << origin;response.setStatusCode(HttpResponse::k403Forbidden);return;}// 添加允许的跨域头,对预检请求返回 204 No Content;//即响应体为空,对应返回的是options字段的预检请求的响应addCorsHeaders(response, origin);response.setStatusCode(HttpResponse::k204NoContent);LOG_INFO << "Preflight request processed successfully";
}/*** @brief 检查给定 Origin 是否在允许列表里* @param origin 来自浏览器请求头的 Origin* @return true 如果允许跨域,否则 false*/
bool CorsMiddleware::isOriginAllowed(const std::string& origin) const 
{return config_.allowedOrigins.empty() || std::find(config_.allowedOrigins.begin(), config_.allowedOrigins.end(), "*") != config_.allowedOrigins.end() ||std::find(config_.allowedOrigins.begin(), config_.allowedOrigins.end(), origin) != config_.allowedOrigins.end();}/*** @brief 给响应添加标准的 CORS 头信息* @param response 当前响应对象* @param origin 本次请求允许的 Origin*/
void CorsMiddleware::addCorsHeaders(HttpResponse& response, const std::string& origin) 
{try {   // 设置允许的 Originresponse.addHeader("Access-Control-Allow-Origin", origin);// 是否允许携带 cookieif (config_.allowCredentials) {response.addHeader("Access-Control-Allow-Credentials", "true");}// 设置允许的方法列表,以,分割if (!config_.allowedMethods.empty()) {response.addHeader("Access-Control-Allow-Methods", join(config_.allowedMethods, ", "));}// 设置允许的自定义请求头列表if (!config_.allowedHeaders.empty()) {response.addHeader("Access-Control-Allow-Headers", join(config_.allowedHeaders, ", "));}// 设置预检结果的缓存时间(单位:秒)response.addHeader("Access-Control-Max-Age", std::to_string(config_.maxAge));LOG_DEBUG << "CORS headers added successfully";} catch (const std::exception& e) {LOG_ERROR << "Error adding CORS headers: " << e.what();}
}
/*** @brief 工具函数:把字符串数组用指定分隔符拼接起来* @param strings 字符串列表* @param delimiter 分隔符,如 ", "* @return 拼接后的字符串*/
std::string CorsMiddleware::join(const std::vector<std::string>& strings, const std::string& delimiter) 
{std::ostringstream result;for (size_t i = 0; i < strings.size(); ++i) {if (i > 0) result << delimiter;result << strings[i];}return result.str();
}

服务端填充响应

这里的响应指的是正常处理客户端发来的请求后,在最终的响应头中添加CORS的相关信息

/*** @brief 请求后钩子,正常请求处理完毕后执行。* 不管是否跨域,都会在最终响应头里加上 CORS 相关头信息。*/
void CorsMiddleware::after(HttpResponse& response) 
{LOG_DEBUG << "CorsMiddleware::after - Processing response";// 直接添加CORS头,简化处理逻辑if (!config_.allowedOrigins.empty()) {// 如果允许所有源if (std::find(config_.allowedOrigins.begin(), config_.allowedOrigins.end(), "*") != config_.allowedOrigins.end()) {addCorsHeaders(response, "*");} else {// 简单处理:只取第一个允许的来源(可以按需改成匹配实际请求来源)addCorsHeaders(response, config_.allowedOrigins[0]);}}
}

抓包分析

在这里插入图片描述
在这里插入图片描述
上图展示了请求与响应的抓包分析数据:当客户端向服务器请求加载登录页面时,服务器不仅会在响应体中返回HTML文件,还会在响应头中附带CORS配置信息供浏览器解析。
CORS 详解,终于不用担心跨域问题了

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

相关文章:

  • 【ArcGISPro】基于Pro的Python环境进行Django简单开发Web
  • 队列和栈数据结构
  • RabbitMQ 高级特性之发送方确认
  • NV133NV137美光固态闪存NV147NV148
  • c++中的绑定器
  • 在Linux服务器上使用kvm创建虚拟机
  • 国内MCP服务平台推荐!aibase.cn上线MCP服务器集合平台
  • 儿童几岁开始可以使用益智玩具?
  • 解决python报not found libzbar-64.dll的问题
  • 基于 SpringBoot+Vue.js+ElementUI 的 “花开富贵“ 花园管理系统设计与实现7000字论文
  • 基于Hadoop的餐饮大数据分析系统的设计与实现
  • 刷卡登入数据获取
  • 纯前端批量下载
  • CPT204-Advanced OO Programming: Sorting排序
  • 扣子空间PPT生产力升级:AI智能生成与多模态创作新时代
  • JS模块导出导入笔记 —— 默认导出 具名导出
  • 行波进位加法器 (Carry-Propagate Adder)
  • UE5 瞄准偏移(AimOffset)功能详解
  • 独立开发者软件出海:如何用Semrush高效洞察与增长
  • RJ45 连接器(水晶头)的引脚定义
  • 贪心专题练习
  • 强实时运动控制内核MotionRT750(一):驱动安装、内核配置与使用
  • 马斯克脑机接口(Neuralink)技术进展,已经实现瘫痪患者通过BCI控制电脑、玩视频游戏、学习编程,未来盲人也能恢复视力了
  • OpenEuler 24.03 用 Ansible 一键完成 SSH 互信 —— 从踩坑到最终方案
  • 站在 Java 程序员的角度如何学习和使用 AI?从 MVC 到智能体,范式变了!
  • 渗透测试中 phpinfo() 的信息利用分析
  • Part 0:射影几何,变换与估计-第三章:3D射影几何与变换
  • 工作中用到过哪些设计模式?是怎么实现的?
  • Robot---能打羽毛球的机器人
  • Linux操作系统之文件(二):重定向