最近新“安排”了一个项目,部门大佬从别的项目搬过来的!
一不小心我也被“安排”得明明白白,总有客户反馈说 他们的账号 为什么登陆上去 什么都看不到,一片空白!
于是,我把和 role 有关的代码看了两遍,然后数据库中的 触发器、函数、存储过程啥的 也都看了一遍,但依然没找到问题所在!
两三天过去了,依然不断有客户反馈,别提心里多 烦了(lz还要抓紧时间写bug呢!)
实在是忍不了这 烦人的 “客户”了
于是通过 logback.xml 配置 将 SQL 语句记录到日志文件中,然后看日志文件找到了问题的根源所在
现在,大家就和我看一下吧
一、配置 logback.xml 文件,将 SQL 记录到日志文件中
<?xml version="1.0" encoding="UTF-8"?> <configuration scan="true" scanPeriod="30 seconds"> <!-- ========================================== --> <!-- 控制台输出日志 --> <!-- ========================================= --> <appender name="console" class="ch.qos.logback.core.ConsoleAppender"> <layout class="ch.qos.logback.classic.PatternLayout"> <pattern>%d{yyyy-MM-dd HH:mm:ss:SSS}[%p]: %m%n</pattern> </layout> <encoder charset="utf-8"> <pattern>%d [%thread] %-5level %mdc{reqSerialNumber} %mdc{currentUser} %logger{36} %line - %msg%n</pattern> </encoder> </appender> <!-- log 通过 LoggerFactory.getLogger(name)取得 --> <logger name="myLog" additivity="true" level="info"> <appender-ref ref="console" /> </logger> <!-- 定义日志文件 输入位置 --> <property name="log_dir" value="D:/logs"/> <!-- 日志文件 appender --> <appender name="file" class="ch.qos.logback.core.rolling.RollingFileAppender"> <filter class="ch.qos.logback.classic.filter.ThresholdFilter"> <level>DEBUG</level> </filter> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <!-- 按天回滚 daily --> <fileNamePattern>${log_dir}/%d{yyyy-MM-dd}/info-log.log </fileNamePattern> <!-- 日志最大的历史 60天 --> <!-- <maxHistory>${maxHistory}</maxHistory> --> </rollingPolicy> <encoder> <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger - %msg%n</pattern> </encoder> </appender> <logger name="org.hibernate.SQL" additivity="false" > <level value="DEBUG" /> <appender-ref ref="file" /> </logger> <!-- 2. 输出SQL 的参数到文件--> <logger name="org.hibernate.type.descriptor.sql.BasicBinder" additivity="false" level="TRACE" > <level value="TRACE" /> <appender-ref ref="file" /> </logger> <root level="DEBUG"> <appender-ref ref="file" /> </root> </configuration>
这个东西也只是粗略看了下文档,不太清楚!有兴趣的大家可以去 官方文档看看
然后记录的日志,我们看一下日志的 SQL 语句,这里就贴出 权限丢失的 一块
这里可以看到 一排下来,全是 delete 语句,当时记得 这个 role 关联的是有51个 account,然后数了一下就是 51 条 delete 语句
我的天,够狠! 一个都不留
然后继续往下翻,就看到了 请求的接口,确定了 接口,那么我们就可以去本地调试咯。
让我们看一看这个接口中的关键代码长啥样,让我 被客户 diss 了这么久
1 public String addRolesToUsers(String roleId, String userIds) { 2 if (!StringUtil.isEmpty(roleId) && !StringUtil.isEmpty(userIds)) { 3 Role role = roleDao.findOne(roleId); 4 List<String> uids = Arrays.asList(userIds.split(",")); 5 Set<Account> users = role.getUsers(); 6 for (Account user : users) { 7 if (!uids.contains(user.getId())) { 8 user.getRoles().remove(role); 9 accountDao.save(user); 10 } 11 } 12 13 for (String uid : uids) { 14 if (uid != null) { 15 Account account = accountDao.findOne(uid); 16 account.getRoles().add(role); 17 accountDao.save(account); 18 } 19 } 20 roleDao.save(role); 21 } 22 return "success"; 23 }
这个 authRyIdentity 接口方法中 调用了上面那个方法,给新生成的 用户 Account 授权
然后发现上面 红色标注的 那块代码(让我知道谁写的,非得弄si他!)
循环遍历 这个role关联的 所有 account,不包含 新生成 的 account 就移除它!(我新生成的 肯定不包含在内 啊)
当时还一度没有怀疑过这个方法,毕竟每次都生成了 一个新的account,还有相应的 权限也正确!!! ~-~
好了,这次的 线上 用户账号权限丢失 问题就到此over了!