本篇文章是对上篇文章【深度解析票据淘汰与过期策略】的一个补充，上篇文章主要分析了TGT的默认淘汰策略配置，ST的配置有TGT的默认配置有一些差异化，特别是ST是基于MultiTimeUseOrTimeoutExpirationPolicy这样一种淘汰策略，本文将详细解析ST的淘汰策略。

文章重点分析源码的过程，不想看分析过程可以直接跳到总结处看结论！！！

---

---

A.相关阅读

• 【CAS6.6源码解析】在IDEA中调试可插拔的supprot模块
• 【CAS6.6源码解析】调试Rest API接口
• 【CAS6.6源码解析】深入解析TGT和ST的唯一ID是怎样生成的-探究ID生成器的设计
• 【CAS6.6源码解析】深度解析默认票据存储策略及其拓展支持-探究存储策略的设计
• 【CAS6.6源码解析】深度解析票据淘汰与过期策略-探究数据淘汰策略的设计

B.ST淘汰策略深入解析

源码位置，淘汰策略从何而来，如何触发清理这些都在上篇文章（ 【CAS6.6源码解析】深度解析票据淘汰与过期策略-探究数据淘汰策略的设计）中详细分析了，这里主要讲ST存在不一样的地方。

1.淘汰策略的获取

从DefaultServiceTicketFactory的determineExpirationPolicyForService方法可以看出，其仍然是采取如下策略：

• 若registeredService中配置了淘汰策略，则使用其中的淘汰策略。
• 若registeredService中没有配置淘汰策略，则使用配置文件中默认的淘汰策略。

注意，这里若registeredService中配置了淘汰策略，返回的是一个MultiTimeUseOrTimeoutExpirationPolicy.ServiceTicketExpirationPolicy实体。

可以进ticketExpirationPolicy.buildTicketExpirationPolicy()里看一下：

发现其也是返回的一样的实体。

由此可以发现，ST使用的是MultiTimeUseOrTimeoutExpirationPolicy这样一种淘汰策略

2.MultiTimeUseOrTimeoutExpirationPolicy

接下来我们看一下这种默认的淘汰策略有何特点，要看一种淘汰策略有何特点，我们只需要关注核心参数、默认配置、过期校验即可。

2.1 核心参数及其默认配置

MultiTimeUseOrTimeoutExpirationPolicy使用了系统配置里面的两个参数，如下：

• numberOfUses：控制服务票证可以在CAS服务器中使用的次数。默认是1。
• timeToKillInSeconds：在CAS服务器中有效的时间。默认是10s。

ST只能使用一次很好理解，但是为什么有效时间这么短呢，才10s？

我们回顾一下授权的流程可以发现，ST是由TGT授予的，ST被授予后应该立即去请求相应的服务，然后相应的服务拿着ST向CAS服务器验证ST是否有效。ST的定位就是针对某一个服务即时授予，短时间内用完一次后ST自然会失效。

2.2 过期校验

过期校验由MultiTimeUseOrTimeoutExpirationPolicy类的isExpired方法完成。核心代码如下：

其主要分为两部分：

• 第一部分校验票据的使用次数，拿ST里面存储的使用次数去和配置的使用次数做比较。
• 第二部分校验票据的过期时间，注意这里校验的逻辑是：ST的创建时间加上配置的过期时间与系统时间进行比对。

然后我们可以看一下ST里面的使用次数是怎么维护的：
是在AbstractTicket的updateTicketState方法中进行维护的，所以票据使用后一般需要更新票据。

到这里，ST的淘汰策略已经清晰明了了。

---

C.总结

• ST使用的是MultiTimeUseOrTimeoutExpirationPolicy这种淘汰策略。这种淘汰策略支持配置使用次数及超时时间。
• ST默认只能使用一次，只存续10s，这也是ST的定位所决定的。

本篇文章只是上篇文章的一个补充，若想看淘汰策略的详细解析，可以查看上篇文章： 【CAS6.6源码解析】深度解析票据淘汰与过期策略-探究数据淘汰策略的设计

---

ATFWUS 2023-08-01