springboot项目CAS结合最新版本shiro工作记录（工作进行中）

这个月的任务是实现在升级的新基础平台上将最新 1.4.0 版本的 shiro 与 CAS 相结合，基础平台以人人代码生成器改进而来。由于旧版本的交互实现类不支持新版本，所以需要尝试修改。虽然基础平台是作为客户端使用的，但还是尝试搭建一下CAS服务端，参考博客。

在搭建过程中，遇到 tomcat8.exe 无法启动的问题：The system cannot find the Registry key for service 'tomcat8'，解决方式是将同一目录下的 service.bat 用 cmd 安装一次。

第二天再次启动CAS服务时，出现tomcat反复装载的问题（后了解到是某些任务到期，需要不断重新加载执行）：

重启系统后，再度运行，此时访问配置的CAS服务地址时，出现响应时间过长的问题。随后选择将当前版本的CAS 更换为 4.1.5 版本，此后运行正常。成功登录后页面如下：

tomcat 中的信息：

此时已经算是初步成功。

在尝试参照公司低版本的开发平台进行整合时，出现无法解析 yml 文件中 placeholder 的问题。改为将参数写死的方式之后，运行项目报 exit code 1，直接退出。询问同事之后了解到，是出现了包冲突的情况。将 shiro 的依赖包版本由 1.3.2 降低为老版本基础平台使用的 1.2.4 后该情况不再出现。 

此时出现了新问题，同事说需要注释掉 quartz schedule 相关实现类中的定时器初始化方法，询问后了解到该方法的存在会令项目在运行时报错，但是不理会也不会有影响。但是实际测试的时候发现如果不将该部分注释掉，运行时会报错:

具体原因待查。IDEA 中可以看到以下报错：                                                                                                                                      

通过查询数据库发现，数据库中留存有基础平台修改前人人代码生成器原有的数据。首先尝试清除。清除完所有的数据之后，成功运行。领导说 quartz 可能会将数据序列化处理之后放进数据库，每次运行时都会尝试将数据反序列化重新匹配，所以如果匹配不上，就会报这个错误。

虽然将其注释掉之后能够运行，但是访问相关地址时会出现“发送的响应无效”问题，此时已经跳转进入cas服处理的页面，猜测是具体连通服务器的代码没有调整好。随后在查阅公司的技术资料时发现旧版本项目的开发人员是将客户端和服务器端同时部署在一起，通过在 deployerConfigContext.xml 文件写入项目使用的数据库连接信息达到目的。并没有做到将CAS作为独立的验证服务器进行部署。因此，如果想要使用旧项目的 CAS 服务，就必须在相关服务器写入本机的数据库连接信息。这种做法效率很低，需要改进。发现该情况后，决定先将本地部署为 CAS 服务端，将 shiro 配通后再考虑优化方案。

将修改好的 cas-sever-webapp 达成 war 包并放入 tomcat 中运行时，登录出现以下报错：，

然而经检查，数据库中并不存在相应的字段，在修改的 cas-sever-webapp 源文件中也没有出现。而且不存在其它模块对于该类所属模块的引用，所以不是版本冲突问题。最后询问同事得知，是由于没有将 cas 源码中的 core 模块加载到 maven 本地仓库导致无法引用类。为防止运行时的端口冲突，将服务器端使用的端口号设置为7070，客户端为8080。

解决问题后运行，可以自动跳转至cas服务端的页面，但是无法验证输入的用户信息，得到如下信息：

推测可能是连接数据库之后使用的表结构不符合 cas 源码中的要求，实际测试后发现原因并非如此。在论坛上看到可能是因为MD5加密后的信息与登录时输入的未加密处理信息不匹配，后经测试也不是该问题。此后进入cas源码查找问题。在idea中直接放入tomcat运行，输入用户名密码后，debug得到如下报错（cas-server-support-jdbc项目下QueryDatabaseAuthenticationHandler 类中的 authenticateUsernamePasswordInternal 方法）：

对应查询语句如下（deployerConfigContex.xml）：

表结构如下：

从代码可以了解到，是使用注入bean的方式对数据库进行操作。