你所不知道的Chrome机制

前段时间,遇到一个诡异的问题,我们有两个系统,一个是主服务,另一个是后台管理系统,但两者用的是同一个域名:

主服务:https://xxx.baidu.com

主服务提供权限验证、接口调用等功能,后台服务管理提供给接口人权限申请、变更权限等操作,只不过主服务是https,而后台管理系统是http。

两个服务是独立部署的,在nginx层面根据路径做了分发(/admin路径的映射到后台服务的Tomcat上面),因为这个架构是很久之前确定的,一直运行没有问题,但近期用户在更新到Chrome-56及以后,频繁的报出后台服务无法登陆的问题。

碰到这种蛋疼的问题,简直就是折磨,老虎啃天,无处下口的感觉,并且只出现在Chrome浏览器中,在Firefox下面正常,万念俱灰,查了好几天,无意中对比了一下Chrome跟Firefox,发现在同时访问两个系统后,在Firefox下面会有两个相同名字的JSESSIONID Cookie(一个Secure的,另一个不是),在Chrome只会有一个安全的JSESSIONID的Cookie:

因为主服务是https的服务,而后台管理服务是http的,所以理论上应该有两个Cookie,一个Secure的,一个非Secure的,大家应该知道secure的Cookie在使用http访问时根本取不到,看到这里问题应该是出在了Chrome浏览器的问题上。

抱着试试看的态度,试了一下旧版本的Chrome,发现是能够写入两个名字相同但安全机制不同的JESSIONID Cookie的,当时的反应会不会是Chrome新版本引入的Bug呢,去Google的Chrome的Bug反馈平台提了issue:

没想到过了一段时间,Chrome的RD还真是答复了我的问题:

原来Chrome最近调整了安全策略,同一个domain下,非secure的Cookie是不能与secure的Cookie重名的,如果重名会导致非secure的Cookie写入失败,所以才会导致没有植入Cookie,访问系统出现异常。

但是他们的这个策略还是很奇怪,我先访问Https的系统写入secure的Cookie,然后再访问Http的系统,这个非secure的Cookie写入会失败,但是颠倒顺序反而两个都能存在,唉,感觉没道理可讲呀。。。

不深究上面的疑问了,搞明白了原理,Chrome无法调整,只能修改Tomcat的sessionid的名字了,其实修改起来还是比较简单,我们将后台管理系统的sessionid的名字改为了ADMIN_JSESSIONID:

我们是Tomcat6,不同版本的Tomcat修改方式略有不同,请大家自行百度。

  • 发表于:
  • 原文链接http://kuaibao.qq.com/s/20180120G00PTE00?refer=cp_1026
  • 腾讯「腾讯云开发者社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券