首先声明,本文中谈及的心得,有很多是尚未得到客观性验证的,纯属笔者在工作实践中的经验之谈,拿来与大家分享,希望大家在工作中碰到相同问题时,能得到快速解决。
这些问题的解决方式都是笔者自己实践摸索的(在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:
这些问题的解决方式都是笔者自己实践摸索的(在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: