CAS 的 proxy granting ticket 在现实中有人用吗？

[JamesMackerel]

https://apereo.github.io/cas/5.3.x/protocol/CAS-Protocol.html#proxy-web-flow-diagram

今天又看了一遍 CAS 协议的 proxy granting ticket，在搞了那么久 CAS 之后感觉自己终于能够大致可能理解这个协议想要做的事了。看上去它能让一个反向代理去代理 CAS 协议，使用户只用登录一次 Proxy 之后就不用再去经过一堆 302 去登录 Proxy 后面的服务。好像这种协议在一个前端对应多个后端服务的场景比较好使？

但是有两个不太懂的地方：

1. 这个协议真的好复杂的样子，而且需要专门为它开发一个 Proxy，真的有人会这么做吗？
2. 看这个协议时序图的意思，Proxy 需要在自己的域名底下种一个 Cookie，但是如果用户访问的是 app 的域名，那这个 cookie 是不是就带不上了？或者说这个协议其实限定了只能在大家都是同一个二级域名的情况下使用？

[0312birdzhang]

没用过，还在用 3.5.2 版本🌚

[JamesMackerel]

@0312birdzhang 看来用 3.x 和 4.x 的大有人在……

[0312birdzhang]

@JamesMackerel #2 看了好几次 5.x，感觉如果不做定制的话更灵活，要是定制的话需要花点时间才行，不像 3.x 直接魔改就行了😂

[JamesMackerel]

@0312birdzhang 3.x 没用过，那个版本难道没有用 overlay，可以直接改他的任何地方的代码？

[0312birdzhang]

@JamesMackerel #4 3.5.3 的代码 https://github.com/apereo/cas/tree/v3.5.3，我是直接改 ldap 的部分集成 2fa 的😂

[JamesMackerel]

@0312birdzhang

妈耶，当时的代码量真的好少哦。5.x 之后都是用 gradle 引入一个超级无敌大的 cas-server-core 的 war 包，想改什么东西都要借助 Spring 的条件依赖注入机制去改，如果实在改不了，还得用 gradle-war-overlay 的 exclude 机制去干掉那个大 war 包里的 jar，然后再把自己魔改过的塞进去。

不过这也只是我的一个思路（ https://blog.dragonslayer.me/archives/161 ），并没有在实际中用过，真的是太难了。

[0312birdzhang]

@JamesMackerel #6 是啊，我之前想升上 5.x 的，看了两次都劝退了，用旧版的苟着吧😂