若依与积木报表集成：Token安全校验全链路实战解析

做Java后端的人多少都碰过这套组合若依管权限积木报表出图表。但把两个东西拼在一起的时候最难受的不是报表样式怎么调而是Token安全校验怎么打通。我也是一路从“页面404”踩到“导出Excel报错”最后把整套流程完整跑通从依赖引入到Token解析把积木报表的鉴权逻辑摸了个底朝天。这篇就按实战顺序把方案怎么选、Token怎么传、坑都在哪儿一次性写清楚给正在折腾“若依积木报表”的朋友做个参考。1. 项目背景与整体方案设计1.1 为什么选若依积木报表这个组合若依RuoYi-Vue在国内Java后端圈子里的占有率不用多说前后端分离、RBAC权限模型、代码生成器这些都是现成的拿来改改就能用特别适合中后台管理系统快速落地。积木报表JimuReport则是一个纯Java的开源报表工具支持在线设计报表、图表、填报和打印最大的优势是集成成本低——引入一个starter配个数据源就能在项目里直接用可视化拖拽的方式出报表。把两者组合起来核心诉求就一句话复用若依的用户体系和权限控制让报表功能成为系统内部的一个模块而不是一个独立的、需要单独登录的“孤岛”。如果放任积木报表自带登录页用户每次看报表都得再输一次账号管理层根本不会接受这种体验。那就必须在集成的同时把若依的Token体系延伸到积木报表的请求链路上。这里先给结论积木报表不是不能直接配个iframe地址用但一旦涉及权限控制和用户身份隔离iframe方案基本就是给自己埋雷。正确做法是后端集成加Token校验统一处理。后面会详细展开。1.2 一个容易被忽视的安全问题很多人在集成时只关注“报表能不能显示出来”忽略了身份认证的闭环。积木报表自带一套登录机制如果不做任何处理它的后台接口、报表数据接口默认是“只要过了积木自己的登录就能访问”。这就意味着攻击者如果拿到了积木报表的访问地址完全可以绕过若依直接访问报表后台甚至通过报表数据接口拖库。所以集成方案的底线要求是积木报表自带登录页不能暴露给最终用户积木报表的所有数据接口必须经过若依的Token校验用户只能通过若依登录后获得的Token访问报表数据不同用户看到的数据范围最好还能根据若依的角色/部门做数据权限隔离。后面第3章会重点说Token校验怎么落到代码里这里先不展开了。1.3 两种集成路线的取舍在实际动手前先想清楚走哪条路能省掉后面大量的返工。路线的本质区别在于积木报表是独立部署还是作为一个模块打包进若依项目。对比项独立部署 iframe 嵌入后端模块集成部署复杂度需要额外维护一个报表服务端口随若依一起启动无额外端口Token 打通难度高需要处理跨域、Cookie、SSO 回调低同上下文直接复用请求头权限控制精度粗粒度基本靠 iframe 地址隐藏细粒度可控制到接口级二次开发效率低改样式要跨项目联调高前后端都在一套代码里多环境发布需要单独配置报表服务的地址随主项目发布不额外增加Jenkins任务我在实际项目中直接选了“后端模块集成”把积木报表当做一个普通的Spring Boot Starter引入到若依工程中。这样报表的Controller和若依的Controller跑在同一个Servlet上下文里Token校验的过滤器天然覆盖到所有请求不存在跨域和Cookie作用域的问题。维护成本也最低一台服务器把前后端和报表全包了。2. 依赖引入与项目结构改造2.1 依赖版本怎么选才不打架积木报表的Spring Boot Starter在Maven中央仓库有正式版本引入方式很简单但版本选择不能拍脑袋。这里有一个需要特别留意的坑积木报表依赖的Spring Boot版本、Mybatis-Plus版本和若依自带的版本不一定一致。以我用的若依Vue 3.8.x为例它内置的Spring Boot是2.5.x、Mybatis-Plus是3.4.x。积木报表1.6.0以上的版本对这些基础组件的兼容性还可以但POI的版本经常发生冲突。积木报表为了支持Excel导出内部依赖了Apache POI 4.1.2而若依的代码生成器或其他依赖可能会引入更高版本的POI这时候Maven的依赖仲裁规则就可能把高版本或低版本覆盖掉导致启动时报出各种NoSuchMethodError。一个稳妥的做法是引入积木报表starter时把它的传递依赖先排除掉再在项目里显式声明统一的版本号。这里给出我最终采用的pom片段。!-- 积木报表 starter -- dependency groupIdorg.jeecgframework.jimureport/groupId artifactIdjimureport-spring-boot-starter/artifactId version1.6.4/version exclusions exclusion groupIdorg.apache.poi/groupId artifactIdpoi/artifactId /exclusion exclusion groupIdorg.apache.poi/groupId artifactIdpoi-ooxml/artifactId /exclusion exclusion groupIdorg.apache.poi/groupId artifactIdpoi-ooxml-schemas/artifactId /exclusion /exclusions /dependency !-- 统一声明 POI 版本 -- dependency groupIdorg.apache.poi/groupId artifactIdpoi/artifactId version4.1.2/version /dependency dependency groupIdorg.apache.poi/groupId artifactIdpoi-ooxml/artifactId version4.1.2/version /dependency这里把POI统一固定为4.1.2是因为积木报表对4.1.2的兼容性最稳。如果你项目里其他模块强依赖POI 5.x那就以实际测试为准但一定要保证积木报表的Excel导入导出功能能正常跑通。2.2 排除自动配置冲突积木报表starter有一个让人头疼的地方它会自动装配自己的数据源和Mybatis-Plus相关配置。如果不加干预启动时可能报“Failed to configure a DataSource”或者和若依的数据源配置冲突。解决方式是在若依的启动类上排除掉积木报表的数据源自动配置类。SpringBootApplication(exclude { org.springframework.boot.autoconfigure.jdbc.DataSourceAutoConfiguration.class, org.jeecg.modules.jmreport.config.JmReportDataSourceConfig.class }) public class RuoYiApplication { public static void main(String[] args) { SpringApplication.run(RuoYiApplication.class, args); } }具体排除哪个配置类取决于你引入的积木报表版本。建议在IDE里搜索一下JmReportDataSourceConfig这个类是否存在不存在就换一个排除目标。这里我提供一个更通用的做法不在启动类上排除而是直接在application.yml里把积木报表的数据源指向若依的主数据源。jimureport: datasource: # 使用默认数据源不单独配置 type: com.alibaba.druid.pool.DruidDataSource driver-class-name: com.mysql.cj.jdbc.Driver url: ${spring.datasource.druid.master.url} username: ${spring.datasource.druid.master.username} password: ${spring.datasource.druid.master.password}这样积木报表直接复用若依的MySQL连接数据源冲突的问题基本能绕开。注意如果你使用多数据源积木报表默认连的是master数据源需要给报表单独指定数据源时再在积木的后台配置里动态添加数据源即可。2.3 菜单挂载的三种方式报表后端集成进来了前端怎么显示我试过三种方式逐一说明优劣。方式一iframe地址直连。菜单URL直接填积木报表的访问地址比如/jmreport/index。这种方式配置最快但它会绕过若依的Token认证因为iframe加载的是一个全新的页面请求请求头里不会自动带上若依的Authorization头。结果就是用户要么看到积木报表自带的登录页要么因为未登录被拦截。方式二后端接口返回报表地址前端跳转。后端写一个接口在接口里校验Token通过后返回积木报表的页面地址前台用window.open打开。这种比方式一强一点但Token一旦过期报表页面里的后续接口请求仍然过不了认证。方式三前端页面加载完毕后用Axios携带Token请求积木报表的接口拿到报表页面数据后再动态渲染。这种是正路它把积木报表的页面访问完全纳入若依的前端路由体系Token在请求头里统一携带。最终我采用的是“方式二方式三”的混合版本页面上直接嵌入积木报表的iframe但iframe的src不是静态地址而是走了一个带Token参数的转发接口。积木报表本身支持token参数后端在转发时把若依的Token拼在URL里积木报表收到Token后会调用我们自定义的校验服务第3章细说。这样既保留了积木报表在线设计器的完整交互能力又绕过了它的登录页。GetMapping(/report/open) public String openReport(String reportCode, HttpServletRequest request) { // 校验当前用户是否已登录 String token request.getHeader(Authorization); if (!StringUtils.hasText(token)) { throw new ServiceException(未登录); } LoginUser loginUser tokenService.getLoginUser(token.replace(Bearer , )); if (loginUser null) { throw new ServiceException(Token已失效请重新登录); } // 拼接带 token 参数的报表地址 return redirect:/jmreport/design/ reportCode ?token token.replace(Bearer , ); }注意Token放在URL参数里有被日志记录的风险所以这里我建议给积木报表单独加一个Header参数读取逻辑能不用URL传就不传。积木报表1.6.0以上版本支持从Header里读token配置一下即可。2.4 菜单权限和积木报表角色绑定若依有角色、菜单、权限点的完整体系。积木报表后台也有自己的角色体系如果放任不管会出现“一个用户在若依里没有报表权限却依然能通过积木报表后台看到所有报表”的漏洞。我的做法是在若依的菜单权限点控制入口同时把积木报表的角色与若依的角色做一层映射。具体来说在若依里创建“报表管理员”“报表普通用户”等角色分配对应的菜单权限然后通过积木报表的接口为每个登录用户创建或关联一个同名的积木用户报表的授权权限交给该积木用户。这个过程在用户第一次打开报表页面时自动完成。// 用户第一次访问时自动同步为积木报表用户 JmReportUserService userService SpringContextUtils.getBean(JmReportUserService.class); JmReportUser reportUser userService.getUserByName(username); if (reportUser null) { reportUser new JmReportUser(); reportUser.setUsername(username); reportUser.setRealname(user.getNickName()); userService.addUser(reportUser); }3. Token安全校验全链路设计3.1 若依的JWT认证体系速览先说若依自身的Token机制不要一上来就写积木报表基础不一样的话后面全是空谈。若依使用的是Spring Security JWTJSON Web Token的无状态认证方案。用户登录成功后后端生成一个包含用户ID、用户名、过期时间等信息的JWT通过Authorization: Bearer token的Header传递给前端。若依的TokenFilter过滤器会拦截所有API请求解析Header中的Token调用TokenService#getLoginUser方法从Redis中读取用户信息并放入Spring Security的SecurityContext中。之所以用Redis是因为若依把JWT和登录会话做了绑定。JWT本身虽然无状态但如果用户修改密码、被管理员踢下线若依需要能立即让该Token失效。所以它的逻辑是JWT里只存一个随机UUID作为key真正的用户会话数据放在Redis里过期时间以Redis里的为最终判断。这也是它叫“无状态JWTRedis会话”的混合方案。搞懂这个之后积木报表的Token校验也就清晰了我们只需要拿到积木报表请求中携带的Token然后调用若依的TokenService#getLoginUser去Redis里查这个用户是否还存在、是否过期。查到了就说明用户是合法登录的查不到就拒绝访问。3.2 积木报表的鉴权扩展点积木报表不是完全没有考虑集成场景。它在设计上留了几个扩展口子其中最关键的是JimuReportTokenServiceI这个接口。官方的说明是实现这个接口后积木报表的请求在访问数据接口时会自动调用实现类里的customToken方法由外部系统来完成Token的校验和用户身份转换。这个接口是打通两套权限体系的关键。注意实现类必须注册为Spring Bean积木报表启动时会自动注入。如果发现你写的实现类没生效大概率是这个原因。接口结构大致是这样的public interface JimuReportTokenServiceI { /** * 自定义Token校验 * param token 请求中携带的token * return 返回用户标识 */ String customToken(String token); }积木报表内部拿到customToken的返回值后会用这个返回值去识别当前用户是谁并把用户信息关联到报表操作上。所以我们只需要在这个接口实现里把若依的Token解析逻辑套进去即可。3.3 自定义Token校验器的完整实现这一步是整个集成的核心代码不多但逻辑必须严谨。以下是我在生产环境使用的实现版本直接写在了若依框架的ruoyi-admin模块里。Component public class JimuTokenServiceImpl implements JimuReportTokenServiceI { private static final Logger log LoggerFactory.getLogger(JimuTokenServiceImpl.class); Autowired private TokenService tokenService; Override public String customToken(String token) { // 容错处理部分场景可能会传空token if (!StringUtils.hasText(token)) { throw new ServiceException(未获取到有效的Token请重新登录); } // 去掉前缀兼容带 Bearer 的写法 String realToken token.startsWith(Bearer ) ? token.substring(7) : token; // 调用若依的TokenService校验Token LoginUser loginUser tokenService.getLoginUser(realToken); if (loginUser null) { log.warn([积木报表] Token校验失败token{}, realToken.substring(0, Math.min(10, realToken.length())) ...); throw new ServiceException(登录状态已过期请重新登录); } // 校验通过返回用户名作为积木报表的用户标识 return loginUser.getUsername(); } }这段代码有几点值得展开第一为什么要在实现类里重新拿一遍loginUser因为积木报表的请求链路和若依的Spring Security过滤器链路不是完全绑定的。如果只是依靠若依的TokenFilter先过滤再进入积木报表的Controller有个顺序问题。直接在customToken里调用tokenService.getLoginUser是最牢靠的它从Redis里取数据即使过滤器顺序有变动这里也能独立完成校验。第二loginUser.getUsername()返回值的含义。积木报表拿到这个用户名后会用它在自己的用户表里查找或创建一条记录之后该用户对报表的增删改查权限都由积木报表自身的权限体系控制。这里有个容易踩的坑如果你返回的是一段随机字符串积木报表每次都会认为是一个新用户已有的角色授权全部失效。所以建议返回稳定不变的若依用户名。第三Token前缀兼容。积木报表如果需要Header方式传Token可能会收到带Bearer前缀的值。我在代码里做了剥离处理避免因为多一个前缀就把Token判失败。3.4 白名单与匿名访问控制Token校验既然要做就得想清楚哪些路径放行、哪些路径必须拦截。积木报表有很多内置的静态资源、验证码接口、字体文件等这些不应该走登录校验否则会拖慢首次加载速度。我建议把以下路径加入若依的匿名访问白名单security: ignore: whites: - /jmreport/eye/** - /jmreport/static/** - /jmreport/css/** - /jmreport/js/** - /jmreport/images/** - /jmreport/font/**同时要注意不能把积木报表的登录接口放行。积木报表默认的登录路径是/jmreport/login如果它被放行攻击者还是能通过直接访问这个路径进入积木报表自己的登录页绕过若依。最直接的办法把这个路径拦截掉或者干脆把积木报表的登录开关关闭。在积木报表的配置文件里有一个开关可以启用外部Token校验模式jimureport: auth: # 启用外部校验 enabled: true # 关闭自带登录页 loginPageEnabled: false这个配置项在不同小版本里名称略有差异如果发现无效就检查一下当前版本的源码里JimuReportConfig这个类有哪些配置字段。实际踩坑之后我的建议是不要依赖这个开关直接在若依的SecurityConfig里把积木报表的自带登录接口加入拦截列表。3.5 Token过期、续期与用户注销Token会过期过期了怎么办这是生产环境一定会遇到的问题。若依的Token默认过期时间是30分钟以Redis为准如果用户在前台停留时间超过30分钟点击报表时Token已经失效那么积木报表的请求就会因为Token校验失败而弹出登录过期提示。解决思路有两种。思路一前端在拿到若依Token后定时调用刷新接口续期。若依本身有刷新逻辑前端request.js里可以判断响应码收到401时自动调用刷新接口换新Token然后再重新发起报表请求。思路二将若依Token的过期时间调长。这个方法简单但降低了安全性Token一旦泄露风险窗口期会很长。我建议不要为了报表而全局调长Token过期时间。更好的做法是实现一个独立的短Token后端在报表转发接口里生成一个有效期只有3分钟的临时票据拼在报表URL中。积木报表在3分钟内的请求都凭这个短票据访问数据接口。这样即使这个票据被打到日志里攻击者能利用的时间窗口也很窄。// 生成短期访问票据 String tempTicket UUID.randomUUID().toString().replace(-, ); redisCache.setCacheObject(report:ticket: tempTicket, loginUser.getUsername(), 3, TimeUnit.MINUTES); // 拼接报表地址 return redirect:/jmreport/design/ reportCode ?ticket tempTicket;在customToken里优先校验ticket再回退到校验Bearer TokenOverride public String customToken(String token) { String username redisCache.getCacheObject(report:ticket: token); if (StringUtils.hasText(username)) { return username; } // 回退到 JWT 校验 LoginUser loginUser tokenService.getLoginUser(token); if (loginUser null) { throw new ServiceException(登录状态已过期请重新登录); } return loginUser.getUsername(); }用户注销场景也要注意。若依退出登录时会把Redis里的会话数据删除同时前端会清除本地的Token。但积木报表内部可能会有自己的缓存用户信息比如在报表页面停留时积木的Session还会保持一段时间。这个不属于越权漏洞但确实会造成“若依退了报表页还能看几分钟”的观感问题。如果要彻底解决得在积木报表的请求链路里每次都校验Token不允许它用Session缓存。4. 实操过程与核心环节实现4.1 前端路由与请求拦截后端配置完成后前端也要同步改。若依Vue项目的utils/request.js里封装了Axios实例默认会在请求头带上Authorization: Bearer token。这个逻辑对普通API接口有效但积木报表通过iframe加载时iframe内部的AJAX请求并不会自动携带这个Header。所以要解决两个前端问题一是在进入报表页面之前确保用户已登录二是把Token通过安全的方式传给积木报表。前端嵌入报表页面的核心代码放到一个新建的ReportIndex.vue组件里。template div classreport-container iframe :srcreportUrl classreport-frame v-ifreportUrl / a-spin v-else tip报表加载中... / /div /template script setup import { ref } from vue; import { getReportAccessUrl } from /api/report; const reportUrl ref(); function openReport(reportCode) { // 去掉多余参数防止意外传入外部地址 const code String(reportCode || ).trim(); if (!code) { this.$modal.msgError(缺少报表编码); return; } getReportAccessUrl({ reportCode: code }) .then(res { // 后端返回带票据的报表地址 reportUrl.value res.data; }) .catch(() { this.$modal.msgError(报表打开失败请检查登录状态); }); } /script注意一个绕不开的问题iframe里的积木报表页面如果跨域调用后端接口浏览器会拦截。我的方案里积木报表和若依跑在同一个域名和端口下不存在跨域。如果你在集成时用了独立端口或者独立域名就得在积木报表服务上配置CORS允许若依前端域名跨域访问并且允许携带Authorization头。这个配置一定要提前验证因为它直接影响报表能否正常渲染。4.2 数据权限不同角色看不同数据Token校验只是第一层数据权限是第二层。积木报表的数据集可以直接写SQL也可以配置成通过参数动态传值。要做好数据权限最常用的方式是在积木报表的SQL数据集里声明一个自定义参数比如${deptId}然后在报表访问时把这个参数的值换成当前用户所属的部门ID。参数从哪来还是从若依的LoginUser里取。我的做法是扩展一下上一章的customToken返回值让积木报表能够拿到更完整的用户信息。这里需要看一下你所用的积木报表版本是否支持在customToken基础上再往报表上下文里塞参数。如果支持可以这样实现Override public String customToken(String token) { LoginUser loginUser parseToken(token); if (loginUser null) { throw new ServiceException(Token无效); } // 把部门ID、角色ID写入积木报表的上下文 JmReportContextHolder.setParam(deptId, loginUser.getDeptId()); JmReportContextHolder.setParam(userId, loginUser.getUserId()); return loginUser.getUsername(); }如果版本不支持就在SQL里用积木报表内置的“系统参数”功能通过数据权限拦截器拼SQL条件。不管哪种方式核心思路是一致的Token校验时把用户信息传递到报表数据层让每条SQL都带上权限条件。4.3 积木报表后台接口的额外保护积木报表后台有很多管理端接口比如saveReport、deleteReport、addDictItem。这些接口默认也需要登录才能操作。集成状态下只要Token校验链路正确这些接口都会被保护住。但有一个细节容易被忽略积木报表的导出接口走得往往是文件流下载有些下载请求在浏览器里是直接用地址栏访问的并不会携带Authorization头这时候就会触发Token校验失败。为了解决文件下载时的Token丢失问题我在积木报表的下载请求路径上额外加了一层GET参数传递。操作方式是在前端的下载按钮点击事件里手动拼接Token为请求参数而不是依赖Header。// 积木报表导出接口手动拼接token function doExport(reportId, format) { const token getToken(); const url /jmreport/view/${reportId}/export?format${format}token${token}; window.open(url, _blank); }对应的后端在解析时先读参数里的token再读Header保证两条通道都能校验通过。4.4 表单设计器动态脚本的XSS防护对症下药说安全。热搜词里提到了“存储型XSS”这个在积木报表的表单设计器里要特别留意。积木报表支持在表单设计器中配置动态脚本理论上可以在报表页面中执行JavaScript。如果这个功能开放给了不可信用户攻击者在设计报表的时候写入恶意脚本其他用户打开这张报表时就会执行脚本形成存储型XSS。我的建议是积木报表的管理员仅限系统管理员角色使用不要给普通用户开放报表设计权限如果业务上必须开放需要在积木报表的数据字典、数据集SQL输入处做好输入校验和转义若依框架自带的XssFilter默认过滤表单字段但对积木报表的动态脚本规则要单独评估必要时在积木报表的配置项中关闭不必要的动态脚本能力。5. 高频踩坑实录与排查技巧5.1 导出Excel报错could not initialize class POI这个报错几乎每个集成积木报表的人都遇到过属于POI类库初始化失败。我遇到的场景是环境里安装了高版本JDKPOI在创建XSSFWorkbook时需要用到JVM内置的XML解析器因为某种模块访问限制导致初始化失败。排查步骤确认POI版本。检查mvn dependency:tree中poi-ooxml的版本是否与积木报表匹配。看有没有多个POI版本并存。如果既有4.1.2又有5.2.3Maven仲裁后可能留下的是不兼容版本。检查JDK版本。POI 4.1.2对JDK 8/11支持良好对更高版本可能出现模块限制问题。如果确认是JDK与POI不兼容升级POI版本并复测积木报表的导出功能。mvn dependency:tree -Dincludesorg.apache.poi如果输出多个版本的POI则在pom里把其他依赖的传递依赖排除掉只保留一个版本。这个操作我在第2章已经写了实际操作时记得在jimureport-spring-boot-starter上排除也在若依其他可能引入POI的模块上排查一遍。5.2 报表页面404与菜单集成失败若依是前后端分离架构前端用Vue Router做路由。如果你新增了一个“报表管理”菜单但点击之后是404大概率是因为前端没有注册对应的路由组件或者路由路径写错了。正确注册路由的方式在若依前端src/router/index.js里增加一个组件路由组件路径指向刚才创建的ReportIndex.vue。同时要在菜单管理后台里配置路由地址并开放视图权限。还有一个隐蔽原因积木报表的页面和若依的前端路由是两套体系如果前端使用了history模式去掉#的那种当用户在浏览器里直接刷新报表页面时请求会先到后端静态资源处理器如果后端没有配置对应的通配转发就会返回404。解决方式是配置一个后端路由兜底把前端路由指向index.html这个配置在Spring Boot里通常叫forward: /index.html的回退规则。Configuration public class WebConfig implements WebMvcConfigurer { Override public void addViewControllers(ViewControllerRegistry registry) { // 前端 history 路由刷新兜底 registry.addViewController(/report/**).setViewName(forward:/index.html); } }注意这个兜底规则不要覆盖API路径否则会把/jmreport/**也兜出去。5.3 Token失效与匿名访问如果用户打开报表时偶尔成功偶尔失败绝大多数情况下是Token时效性问题。前面提过若依Token默认30分钟过期。用户停留超过30分钟后在报表页面执行操作积木报表拿到过期的TokencustomToken抛异常报表数据请求直接挂掉。排查方法在customToken方法里加日志打印接收到的Token和校验结果。追踪Redis里这个Token对应的key是否还存在。看浏览器网络请求面板观察报表请求是否携带了正确的Header或参数。另一个场景是积木报表的某些静态资源接口不在若依过滤链范围内导致浏览器直接访问时报401或302但页面部分加载。这个问题可以通过给积木报表的静态资源路径加入匿名白名单解决但要控制粒度放行的路径越少越好。5.4 表单设计器动态执行脚本与存储型XSS再强调一次积木报表表单设计器支持动态执行脚本务必对脚本内容做校验。不要把整个报表设计器直接暴露给所有登录用户只给可信管理员开放。若依自带的防XSS过滤器只对普通请求参数生效积木报表的动态脚本处理走的是另一套逻辑需要单独查阅当前版本的文档确认是否支持关闭。如果确实需要支持脚本建议增加服务端白名单校验只允许特定域名下的脚本执行不允许alert、eval、fetch等危险函数。这个防线做在前端是不够的攻击者可以绕过前端直接提交恶意数据服务端必须做一层严格过滤。6. 集成完成后的扩展方向积木报表和若依打通Token校验只是第一步真正到生产环境里你会发现还有不少可以继续完善的地方。一个是报表访问统计。积木报表自带访问统计但它是独立于若依体系的。如果希望统计到每个用户在报表模块的操作记录可以在customToken校验成功后把用户访问报表的日志写入若依的操作日志表这样后台审计能统一看到“谁在什么时候看了哪张报表”。另一个是数据权限深度绑定。如果业务需要“省级账号只能看省级数据市级账号只能看市级数据”简单的Token校验就不够用了。需要在积木报表的数据集参数里根据用户的部门ID、角色编码动态拼接过滤条件。这个思路我在前面第4章提过实际做的时候要把部门和角色编码统一维护成一套规则避免一个项目里若依一套、积木一套。还有一个方向是积木报表的异步导出。大数据量报表导出时接口容易超时。建议把导出任务提交到线程池或消息队列生成文件后再通过若依的通知中心推送下载链接。这个改造不复杂但体验提升非常明显用户不需要一直死死盯着浏览器等导出完成。我个人的体会是报表功能最怕的不是技术难而是权限边界模糊。Token校验做扎实了后续所有权限扩展都站在同一个地基上。如果这一步图省事用了iframe白嫖地址或者干脆把积木报表的登录页露出来后期报表越来越多、用户越来越多再回头补安全会异常痛苦。先把Token闭环打通后面的路就好走了很多。