1. 若依框架跨域问题全景解析作为国内主流的企业级快速开发框架若依Ruoyi在实际部署中经常面临跨域访问的挑战。最近在技术社区看到不少开发者反馈前后端分离模式下明明按照文档配置了CORS为什么还是出现Access-Control-Allow-Origin报错 这个问题看似简单实则涉及网络协议、框架配置、部署环境等多重因素。本文将结合若依4.7.5版本从HTTP协议层到代码实现层彻底讲透跨域问题的解决方案。关键提示跨域问题本质是浏览器的安全限制与服务端通信能力无关。即使看到401/403状态码也要先解决CORS问题才能进行后续调试。2. 跨域原理深度剖析2.1 浏览器同源策略机制同源策略Same-Origin Policy要求协议、域名、端口三者完全一致。在若依前后端分离架构中常见以下典型场景会触发跨域开发环境前端8080端口访问后端9200端口生产环境主站域名访问api子域名测试环境IP直连访问域名服务2.2 预检请求Preflight机制对于非简单请求如Content-Type为application/json浏览器会先发送OPTIONS请求进行预检。若依框架中以下操作会触发预检使用RequestBody接收JSON参数自定义请求头如携带tokenPUT/DELETE等非标准方法// 典型触发预检的若依控制器代码 PostMapping(/update) public AjaxResult update(RequestBody SysUser user) { return success(userService.updateUser(user)); }2.3 CORS响应头核心参数响应头作用若依配置示例值Access-Control-Allow-Origin允许的源域名* 或 https://ruoyi.vipAccess-Control-Allow-Methods允许的HTTP方法GET,POST,PUT,DELETEAccess-Control-Allow-Headers允许的请求头Authorization,Content-TypeAccess-Control-Max-Age预检结果缓存时间秒36003. 若依框架跨域配置实战3.1 基础版Spring Boot配置类在ruoyi-admin模块的config包下新增CorsConfigConfiguration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOrigins(*) .allowedMethods(GET, POST, PUT, DELETE) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); } }常见坑点allowCredentials(true)时不能使用allowedOrigins(*)必须指定具体域名3.2 进阶版Nginx层统一处理在生产环境推荐使用Nginx统一处理跨域避免每个应用重复配置server { listen 80; server_name api.ruoyi.vip; location / { add_header Access-Control-Allow-Origin $http_origin; add_header Access-Control-Allow-Methods GET,POST,PUT,DELETE,OPTIONS; add_header Access-Control-Allow-Headers Content-Type,Authorization; add_header Access-Control-Allow-Credentials true; if ($request_method OPTIONS) { return 204; } proxy_pass http://127.0.0.1:9200; } }3.3 特殊场景Sa-Token整合方案当集成Sa-Token时需要额外处理token相关头部// 在SaTokenConfig中补充配置 Configuration public class SaTokenConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOrigins(https://admin.ruoyi.vip) .allowedMethods(*) .allowedHeaders(satoken, Content-Type) .exposedHeaders(satoken) .allowCredentials(true); } }4. 疑难问题排查指南4.1 常见报错与解决方案错误现象根本原因解决方案403 Forbidden (CORS preflight channel error)预检请求未通过确保OPTIONS请求返回200/204Missing CORS header Access-Control-Allow-Origin响应头未正确配置检查Nginx或Spring配置是否有误Credential is not supported if the CORS header Access-Control-Allow-Origin is *凭证模式与通配符冲突改用具体域名并开启allowCredentials4.2 浏览器调试技巧Chrome开发者工具中Network标签勾选Disable cache过滤选项输入OPTIONS查找预检请求查看Response Headers是否包含CORS相关头使用curl模拟预检请求curl -X OPTIONS http://api.ruoyi.vip/user/list \ -H Origin: http://localhost:8080 \ -H Access-Control-Request-Method: POST \ -H Access-Control-Request-Headers: content-type \ -I4.3 若依特定问题排查场景1代码生成器接口跨域在ruoyi-generator模块单独添加配置Bean public FilterRegistrationBeanCorsFilter generatorCorsFilter() { UrlBasedCorsConfigurationSource source new UrlBasedCorsConfigurationSource(); CorsConfiguration config new CorsConfiguration(); config.addAllowedOriginPattern(*); config.addAllowedHeader(*); config.addAllowedMethod(*); source.registerCorsConfiguration(/tool/gen/**, config); return new FilterRegistrationBean(new CorsFilter(source)); }场景2Swagger文档跨域在application.yml中增加spring: mvc: pathmatch: matching-strategy: ant_path_matcher5. 安全加固建议生产环境务必指定具体域名而非通配符.allowedOrigins(https://admin.ruoyi.vip, https://mobile.ruoyi.vip)敏感接口建议结合CORS与权限校验PreAuthorize(ss.hasPermi(system:user:edit)) PostMapping(/update) public AjaxResult update(RequestBody SysUser user) { // 业务逻辑 }定期检查CORS配置是否被恶意修改-- 监控系统参数表变更 SELECT * FROM sys_config WHERE config_key LIKE %cors% AND update_time DATE_SUB(NOW(), INTERVAL 1 DAY);实际项目中我们曾遇到Nginx配置被意外覆盖导致跨域失效的情况。后来通过在若依系统监控中增加配置变更提醒彻底解决了这类问题。建议大家在解决基础跨域问题后进一步考虑这种防御性编程措施。
1. 若依框架跨域问题全景解析作为国内主流的企业级快速开发框架若依Ruoyi在实际部署中经常面临跨域访问的挑战。最近在技术社区看到不少开发者反馈前后端分离模式下明明按照文档配置了CORS为什么还是出现Access-Control-Allow-Origin报错 这个问题看似简单实则涉及网络协议、框架配置、部署环境等多重因素。本文将结合若依4.7.5版本从HTTP协议层到代码实现层彻底讲透跨域问题的解决方案。关键提示跨域问题本质是浏览器的安全限制与服务端通信能力无关。即使看到401/403状态码也要先解决CORS问题才能进行后续调试。2. 跨域原理深度剖析2.1 浏览器同源策略机制同源策略Same-Origin Policy要求协议、域名、端口三者完全一致。在若依前后端分离架构中常见以下典型场景会触发跨域开发环境前端8080端口访问后端9200端口生产环境主站域名访问api子域名测试环境IP直连访问域名服务2.2 预检请求Preflight机制对于非简单请求如Content-Type为application/json浏览器会先发送OPTIONS请求进行预检。若依框架中以下操作会触发预检使用RequestBody接收JSON参数自定义请求头如携带tokenPUT/DELETE等非标准方法// 典型触发预检的若依控制器代码 PostMapping(/update) public AjaxResult update(RequestBody SysUser user) { return success(userService.updateUser(user)); }2.3 CORS响应头核心参数响应头作用若依配置示例值Access-Control-Allow-Origin允许的源域名* 或 https://ruoyi.vipAccess-Control-Allow-Methods允许的HTTP方法GET,POST,PUT,DELETEAccess-Control-Allow-Headers允许的请求头Authorization,Content-TypeAccess-Control-Max-Age预检结果缓存时间秒36003. 若依框架跨域配置实战3.1 基础版Spring Boot配置类在ruoyi-admin模块的config包下新增CorsConfigConfiguration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOrigins(*) .allowedMethods(GET, POST, PUT, DELETE) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); } }常见坑点allowCredentials(true)时不能使用allowedOrigins(*)必须指定具体域名3.2 进阶版Nginx层统一处理在生产环境推荐使用Nginx统一处理跨域避免每个应用重复配置server { listen 80; server_name api.ruoyi.vip; location / { add_header Access-Control-Allow-Origin $http_origin; add_header Access-Control-Allow-Methods GET,POST,PUT,DELETE,OPTIONS; add_header Access-Control-Allow-Headers Content-Type,Authorization; add_header Access-Control-Allow-Credentials true; if ($request_method OPTIONS) { return 204; } proxy_pass http://127.0.0.1:9200; } }3.3 特殊场景Sa-Token整合方案当集成Sa-Token时需要额外处理token相关头部// 在SaTokenConfig中补充配置 Configuration public class SaTokenConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOrigins(https://admin.ruoyi.vip) .allowedMethods(*) .allowedHeaders(satoken, Content-Type) .exposedHeaders(satoken) .allowCredentials(true); } }4. 疑难问题排查指南4.1 常见报错与解决方案错误现象根本原因解决方案403 Forbidden (CORS preflight channel error)预检请求未通过确保OPTIONS请求返回200/204Missing CORS header Access-Control-Allow-Origin响应头未正确配置检查Nginx或Spring配置是否有误Credential is not supported if the CORS header Access-Control-Allow-Origin is *凭证模式与通配符冲突改用具体域名并开启allowCredentials4.2 浏览器调试技巧Chrome开发者工具中Network标签勾选Disable cache过滤选项输入OPTIONS查找预检请求查看Response Headers是否包含CORS相关头使用curl模拟预检请求curl -X OPTIONS http://api.ruoyi.vip/user/list \ -H Origin: http://localhost:8080 \ -H Access-Control-Request-Method: POST \ -H Access-Control-Request-Headers: content-type \ -I4.3 若依特定问题排查场景1代码生成器接口跨域在ruoyi-generator模块单独添加配置Bean public FilterRegistrationBeanCorsFilter generatorCorsFilter() { UrlBasedCorsConfigurationSource source new UrlBasedCorsConfigurationSource(); CorsConfiguration config new CorsConfiguration(); config.addAllowedOriginPattern(*); config.addAllowedHeader(*); config.addAllowedMethod(*); source.registerCorsConfiguration(/tool/gen/**, config); return new FilterRegistrationBean(new CorsFilter(source)); }场景2Swagger文档跨域在application.yml中增加spring: mvc: pathmatch: matching-strategy: ant_path_matcher5. 安全加固建议生产环境务必指定具体域名而非通配符.allowedOrigins(https://admin.ruoyi.vip, https://mobile.ruoyi.vip)敏感接口建议结合CORS与权限校验PreAuthorize(ss.hasPermi(system:user:edit)) PostMapping(/update) public AjaxResult update(RequestBody SysUser user) { // 业务逻辑 }定期检查CORS配置是否被恶意修改-- 监控系统参数表变更 SELECT * FROM sys_config WHERE config_key LIKE %cors% AND update_time DATE_SUB(NOW(), INTERVAL 1 DAY);实际项目中我们曾遇到Nginx配置被意外覆盖导致跨域失效的情况。后来通过在若依系统监控中增加配置变更提醒彻底解决了这类问题。建议大家在解决基础跨域问题后进一步考虑这种防御性编程措施。
