项目场景:系统:Centos7.3,CAS:3.2.1
生产环境window有一套应用,使用单点登录(shiro+cas),最近把应用迁移到Linux,寻思这还不简单,配置jdk,tomcat一扔,启动,随便试了个账号登录没问题,大功告成
问题描述:个别用户登录报错
第二天客户B反馈账号无法登录,寻思不应该啊(又用A账号登录下没问题)好吧,看日志吧,扫了眼错误信息如下:
原因分析:编码问题
既然是编码问题,第一反应就是修改tomcat字符集,server.xml、catalina.sh等常规文件修改一遍后重启还是报错
打印日志
首先找到报错的xmlUtils文件(反编译或者gitHub下载源码都可以)增加打印日志,看看xml数据具体是什么内容
解决方案:一劳永逸
临时方案
既然修改tomcat编码不起作用,那就把Linux服务器的改为gbk,然后重启tomcat后,虽然可以正常登录,但是正常的业务日志全部都是乱码。
最终方案
网上搜索后发现有人遇到类似情况参考,没有采用这种方式,我是直接改Cas20ServiceTicketValidator这个类,代码如下:
public class Cas20ServiceTicketValidator extends AbstractCasProtocolUrlBasedTicketValidator {
public Cas20ServiceTicketValidator(final String casServerUrlPrefix) {
super(casServerUrlPrefix);
String os = System.getProperty("os.name").toLowerCase();
log.info("os:" + os);
if (os.indexOf("windows") < 0) {
super.setEncoding("gbk");
log.info("not windows set encoding to gbk");
}
this.proxyRetriever = new Cas20ProxyRetriever(casServerUrlPrefix, getEncoding());
}
总结
- cas默认一般是gbk,然后我们知道window默认也是gbk,所以在window上是没问题的
- Cas20ProxyReceivingTicketValidationFilter.java中,getTicketValidator方法里设置的默认编码方式是null。根据测试当默认编码方式是null时只能识别到GBK模式或者gb2312的编码,所以才会造成登录报错。