你所不知道的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修改方式略有不同，请大家自行百度。