分享企业应用集成中的一些心得（SSO、Http session、域名解析）

首先声明，本文中谈及的心得，有很多是尚未得到客观性验证的，纯属笔者在工作实践中的经验之谈，拿来与大家分享，希望大家在工作中碰到相同问题时，能得到快速解决。

这些问题的解决方式都是笔者自己实践摸索的(在google和几大论坛上没找到相关资料 :wink: )，如果有说的不对的，有高人知道确切的原因的，请不吝赐教，先谢过！

[size=x-large][b]
问题1：关于相同域名下多个应用集成的session冲突。[/size][/b]

[b]问题背景：[/b]
公司要集成3个应用到portal上，包括：OA、ERM和HR。开始时，规划使用统一的域名oa.xxxxxtechnology.com。由于HR是外购的系统，并且只能部署与tomcat5.5的root路径下，因此单独部署一个Tomcat服务器实例，占用8080端口。OA和ERM共同部署在一个Tomcat6.0下，ERM部署与root路径下，OA部署在/OA的路径下，两个应用都占用80端口。三个系统集成在同一个portal平台上，页面采用DIV嵌IFrame方式集成，系统间采用CAS实现SSO。

[b]出现的问题：[/b]
用户登录后，在OA系统和ERM系统间切换运行正常，但进入到HR系统后，再切到ERM系统，发生session过期，而从HR切入OA系统则不会。

[b]实验发现的原因[/b]
虽然HR与ERM部署与不同的Tomcat，并且采用不同的服务端口，但由于使用相同的域名oa.xxxxtechnology.com，且应用路径都是root，对于浏览器而言，他们共用相同的Session，因此会发生session覆盖问题。[color=red]笔者作了相关的实验，证明HR与ERM的session是相互覆盖的。[/color]
实验结论是，浏览器依靠域名和应用的上下文路径来建立session关联，且与端口号无关。反过来，也证实了同一个应用可以使用多个端口。

[b]解决方式[/b]
1.采用不同的上下文，如，将ERM的上下文路径从root变为/erm
2.采用子域名，如，将HR映射为hr.xxxxxtechnology.com,将ERM映射为erm.xxxxxtechnology.com.


[size=x-large][b]
问题2：关于IE6.028xxx版本的重定向问题（应该是BUG）
[/size][/b]

[b]问题起因：[/b]
这个问题发生的有些诡异，目前我们对其没有很明确的解释。因此我们倒过来，先说结果。
问题发生在CAS的sso中。造成问题的原因有两个：
1.CAS的一个认证URL配置错误。我们将https://oa.xxxxxtechnology.com:9443/cas/login的链接配置成了https://oa.xxxxxtechnology.com:9443/cas/logi，少了一个n。
2.IE6.028版本的redirect处理存在bug

[b]问题的表象[/b]
1.我们在[color=red]除了IE6.028xxx版本外[/color]的其他浏览器上运行都正常，这包括了windows2003和XP上的IE6.039xxx，Firefox3.0，Google Chrome1.0.x等。唯有windows2000下IE6.028xxx版本不能正常重定向。
在IE6.028xxx上，最终显示的重定向链接是https://oa.xxxxxtechnology.com/cas/login
[color=red]从这个表象上看，更像是端口号丢失，而不是链接写错[/color]，这个误导了我们很久一段时间。

2.使用正确的链接进行重定向后，页面上的图片和css都无法正确载入，后来发现页面base path中端口号不对，原因是request.getServerPort()方法返回的端口号是错的。

[b]问题的一个猜想[/b]
通过sniffer软件对Http请求报文的分析发现，对于CAS的重定向请求，Tomcat返回给浏览器的是HTTP302 Temporarily Moved应答，且重定向的URL为（错误的）https://oa.xxxxxtechnology.com:9443/cas/logi。对于这个应答，浏览器会尝试重定向URL，但如果给定的URL失败，应该会采用相似的URL进行匹配，这点是笔者的猜测，否则无法解释错误的URL https://oa.xxxxxtechnology.com:9443/cas/logi到了浏览器端会被替代成https://oa.xxxxxtechnology.com:9443/cas/login。

[b]问题中发现一个IE6.028xx的BUG[/b]
IE6.028xxx版本对HTTP302 Temporarily Moved的重定向采用HTTP1.0协议，而不是HTTP1.1协议（同样的请求在Firefox3.0中是HTTP1.1协议）。最关键的是它对于相同HOST上不同端口的redirect存在端口号不更改的BUG，就是说，如果你从http://www.aaa.com:8080/aaa.html重定向到http://www.aaa.com:9443/bbb.html时，HTTP1.0的头部HOST属性中仍然是8080端口，这个bug被实验验证是存在的。当然如果HOST的名字不同，则不会出现这个bug。

[b]解决方法[/b]
将CAS部署和OA服务器分离，让CAS服务使用cas.xxxxxtechnology.com的二级域名。

[b]问题总结[/b]
1.因为一个重定向链接不正确，造成了浏览器采用了URL的自动匹配策略算法，目前对这种自动匹配，本人尚未找到官方资料证实，只是从表象上推测。
2.URL的自动匹配算法使用到了HTTP head中的HOST属性，但是IE6.028版本对于相同HOST上不同端口的redirect过程，存在bug，不会修改head中host属性的端口号。（这也是造成上述假象的根本原因）
3.IE6.028版本中的对HOST属性的错误，会影响servlet中request.getServerPort()这个方法的结果，造成JSP页面的相对路径不正确。

[b]
[size=x-large]经验总结[/size]
[/b]
在一个企业应用环境中集成多个系统，不论是portal还是ESB/SOA的实施，建议给每一个应用一个二级域名。这样既可以解决js在页面上跨域调用的问题，又可以保证应用session的相对独立，还可以避免部分浏览器bug造成的redirect问题！

因为问题比较复杂，咖啡已经尽力的试图将问题说清楚了，不过看起来还是有点晕 :wink: