CAS-Protocol:
https://apereo.github.io/cas/5.2.x/protocol/CAS-Protocol.html
与一般token机制不同,想成功认证CAS需要sessionId与ticket两个
这两个值可以去服务器查看日志获得
sessionId:
认证后的sessionId会存储在redis中,可以避免session丢失问题

2020-08-20 15:23:19.319 [DEBUG] [qtp1665967079-42] com.foo.bar.web.shiro.MyCasFilter(MyCasFilter.java:58) - login success...,sessionId=15253ce9-dc99-4843-967d-e7e79d6895f2,token={"principal":"01374750","credentials":"ST-196445-YIkgOispAi4voQjxUeZx-casnode1","rememberMe":false}
SHARE_SESSION_ID=15253ce9-dc99-4843-967d-e7e79d6895f2; Path=/spsp-app; Domain=localhost; HttpOnly;

ticket:
2020-08-20 15:23:19.348 [INFO] [qtp1665967079-42] com.foo.bar.web.filter.LogFilter(LogFilter.java:109) - 请求URL:/foo/bar/login/userInfo;jsessionid=dpmz1e2ikxcj17v7268uk13c7?ticket=ST-196445-YIkgOispAi4voQjxUeZx-casnode1, total time:62 ms, userCode:null, responseCode:200,
错误:
ticket 'ST-195205-1174j1jBAS2OfFCchfZ9-casnode1' does not match supplied service. The original service was 'http://foo.bar.com/foo-bar/sfim/login/userInfo' and the supplied service was 'http://10.206.104.118/foo-bar/sfim/login/userInfo'.
解决:
可以在nginx上将Host写死成域名
location /foo-bar/ {
proxy_set_header Host foo.bar.com;
proxy_pass http://10.206.104.118/foo-bar/;
}
本文深入解析CAS认证协议的工作机制,重点介绍sessionId与ticket在认证过程中的作用及获取方式。通过实例展示如何在服务器日志中查找这些关键信息,并讨论了在分布式环境下通过Redis存储sessionId来避免session丢失的问题。同时,文章还提供了当ticket与服务不匹配时的解决方案,建议通过配置nginx将Host写死为域名来确保一致性。
945

被折叠的 条评论
为什么被折叠?



