CAS开篇--基于请求理解CAS流程

突然写了一篇关于CAS的文章，也是够了，由于恰巧项目中在和移动端交互时出了一点问题，发现之前CAS的了解还是不够清楚，再次重新记录一下。

对于CAS的安装什么鬼玩意儿的，自己架构实现的，暂时不去管了，笔者项目中是spring-secret集成的。之前看过，但是没有笔记，也不想记录了，本篇就如标题，流程分析。

下图为笔者重划图，CAS的时序图看的不是很清晰，只能自己重新划

还是结合项目的请求来说吧。

1. 首先请求 127.0.0.1:8080/xxxxx ，此时请求头内并没有Cookie信息的存在，因此项目中生成了一个新的Cookie并返回给浏览器，临时会话就此产生。

name : JsessionId  value: 12345678A。这个就是记录在浏览器中和项目的会话Cookie，之后的请求都会带着，那么翻了一下代码，这个存储在浏览器的Cookie有效期为30天，这个Cookie记录的JsessionId记录在项目中的redisSession中，设置的有效期为30分钟。其实当第一次请求之后，如果授权成功的话，之后的请求都会带着Cookie的JsessionId去访问系统，系统发现这个JsessionId还没有失效，说明当前为登录状态，就不需要再去CAS拿这个用户的登录信息了。如果失效的话，这种情况下面再说。

2. 此时系统为当前用户记录了一个临时会话，保存的Id值就是Cookie的JsessionId，但是此时用户还未登录，在响应头中可以看见一个location 的URL，这个就是去登录CAS的。可以看见，login请求返回了一个登录页面，此处由于未登录，如果此处是登录的情况，那么返回时不一样的，下面讨论。响应头内也返回了一个Cookie 的JsessionId，可以猜测和系统中使用的是一套东西。

3.翻看浏览器的记录也能发现，当前维护的会话是哪些。一个是当前系统的会话，一个事CAS的会话。

4.下一步就是登陆了。看看登陆时操作了什么，首先是POST请求CAS的login请求。可以看见这个login请求返回的是个302 URL。也就是下面的带有票据 ticket的check请求。

那么通过这种方式发给系统，带有ticket。系统得到这个ticket之后，会在后台发送一个请求并带上这个ticket去CAS验证用户使用这个合法的ticket，验证有效后，返回用户信息。最终302 到一开始访问的接口上，执行请求。此次login请求成功返回之后，其实在Cookie中记录了一个叫CASTGC的东西。TGC存放了CAS服务端实现的叫做TGT的id，其实这个就是为之后系统判定用户session失效后需要重定向到CAS去时带的东西，如果找到，说明用户之前登陆过，就不需要二次登录了。

5.到此，一次请求结束，那么CAS和用户就建立起了一个联系。CAS记录了这个用户的登录信息。TGT，利用Cookie实现保存了TGC，里面记录了TGT的id。

 

总结： 一次未授权登录过的请求执行时，最终会有两个Cookie生成，一个是用户与系统的，里面记录了JsessionId，这个会话在本系统的有效期为30分钟，这个30分钟是相对时间的概念。是一次请求和上次请求只要在间隔的30分钟内，就不需要重定向到CAS去，而这个Cookie本身的有效期为30天，这是一个绝对时间的概念，在30天内，这个Cookie是有效的，但是里面的的JSessionId的相对间隔时间只有30分钟，这个是笔者公司的项目设计如此，不同的公司设计的是不一样的。

 

接下来为二次请求同一系统，二次请求时会带着JSessionId，

1.如果未失效的话，也就是系统判定为用户为登录状态，直接返回资源。

2.如果失效的话，会重定向到CAS去，请求如下。注意和第一次的区别，第一次请求时，请求头内只有Cookie，并没有TGC信息。第二次请求时带上了TGC信息，这个信息就是去找存储在CAS的TGT信息，如果TGT存在的话，直接请求location中的URL，这个URL带上了ticket票据信息。这边和第一次登陆时差不多，但是和CAS的登录授权又有区别了，相当于这边不在需要你登录了，直接给你跳转到你的实际请求中去了。此处和CAS交互的JsessionId的过期时间暂时不知道，只知道这个Cookie本身的失效时间为30天。

 

接下去就是登录另一个系统了，暂且成为B。发现另一个系统的Cookie也生成。

请求CAS的时候还是获取之前登录过的TGC信息去CAS端获取这个用户的登录信息，此处就是不知道当前Cookie中的CAS的tsid在公司CAS服务器的Session设置的有效时间为多长，所以不好判断，如果这个tsid也失效，会出现什么情况。暂且忽略吧。此处请求发现了登录状态，所以响应成功，跳转到原始请求页面。结束。

 

 

至此分析结束。只是基于请求状态和流程图分析了这个过程，无奈CAS服务端的实现并不能看见，所以无法进一步分析，CAS里面的详细处理过程，不过以上流程应该足够你应付很多的场景了。先结帖，以后有幸的话再来更新吧。

最后贴一张清晰图