耶鲁大学的CAS单点登录，相信在很多项目都有用到了。string在的公司做了个portal的产品，集成CAS。最近几个项目上线，遇到了一些问题，记录下来，备查。

--------------------------杭州某项目--------------------------

F5上挂着CAS，两台weblogic + EOS 所做的集群，自己用ext实现的门户，EOS集群开启了session复制。

问题：

登录操作，登出后，服务器端session没有清除掉。

如下验证：

不关闭IE，在IE中以其他用户登录，会访问到上一个用户的内容。

解决方案：

在F5上配置规则，强制让F5到后端对应的机器登录登出。

对CAS的修改：

把CAS client 的代码，getSevice的方法返回的service的地址加上本node的IP。让F5根据此规则做转发。

问题搞定。

------------------------上海某项目---------------------

apache上挂着CAS，两台jboss + portal + EOS 所做的集群，EOS集群由于代码的原因，无法开启session复制。

问题：

登录操作，偶尔会后台出现must be login 提示，也就是说，没有登录。

如下验证：

用loadrunner录制脚本，用脚本回放10次，偶尔会出错。

预计解决方案：

想根据上个项目的方法改动cas client后用apache做url rewrite。

实际测试结果：

无效，apache相对来说比较弱。

开始纠结…………

----------------------------问题分析------------------------

综合上面2个项目，问题的根本在于：

对于负载均衡来说（F5，apache，nginx），CAS server和用户的IE，永远是2个cookie。

运气好，发到一起去了，就成功。

运气不好，没发到一起，就失败了。

把部署结构的可行性依赖于负载均衡，很可恶。

------------------------解决方案-------------------------

在CAS server登录时，取到当前IE中对于本域名的cookie，让CAS server强行使用和用户IE相同的cookie。

所有的负载均衡都能启动session粘滞。那么，CAS server发出的关于登录，注销的一些请求，就能和用户发出的请求发送到同一台服务器。

这样，问题就能搞定了。

----------------------总结------------------------

不能被别人牵着鼻子走，要独立思考。

找到问题的本质，从本质出发，会更快。

=============update==============

解决方案能解决这个问题，但本质的问题还有一层。

eos的filter，http 接入的时候，采用非portal模式，会直接跳转到预先指定的页面。

session能初始化，但是后台还是会有must be login。

如此。