分析一次自动登录引起的风波，并提供对Cookie的处理方式

前言：最近在开发APP期间遇到的最无厘头的问题就是自动登录遇到的问题，一次偶然的机会发现问题所在，这里分享一下。

现象

我们APP内置了一个自动登录的功能，流程就是在当APP打开时，立刻去进行一次自动登录，但是自动登录不能阻塞当前用户的操作，主界面上数据，列表，版本验证，都要去做。以及用户的操作也不允许用弹框方式阻挡，需要做到用户无感知登录。但是有时候会发现有时候用户提示登录成功了，但是去操作别的操作的时候，依旧提示未登录

用户反馈一多，昨天就决心彻底解决这个问题，从本地网络，到模拟器模拟网络差，网络好、终于让我在一次发现了这个问题所在：这里贴一部分日志：

HttpRetrofit: Set-Cookie: JSESSIONID=0380D455A4A60299E060EFA6E9BD73D2;  HttpOnly
HttpRetrofit: Content-Type: text/html;charset=UTF-8
HttpRetrofit: Set-Cookie: JSESSIONID=E3E81C0FB84894ED61480AD5092EDCD9; HttpOnly
HttpRetrofit: Content-Type: text/html;charset=UTF-8
HttpRetrofit: Set-Cookie: JSESSIONID=E3E81C0FB84894ED61480AD5092EDCGB; HttpOnly
HttpRetrofit: Content-Type: text/html;charset=UTF-8

看到没有？这里竟然在往本地写入三次SESSIONID？？搞过Web的人都知道，JESSIONID就是服务端与客户端之间维持联系的一个ID，那为什么我这里会写入三个呢？？

这里我说明一下，我在当APP打开的时候，会分别去请求：

• 自动登录
• 检查版本
• 加载首页列表
• Banner列表，以及Banner图片的加载

来解释一下为什么服务器会向APP写入三个SessionId，因为当四个请求同时向服务器发起请求，那么对于服务器来说，就是四个新的客户端进来，因为你链接进去的时候，没有携带任何信息，所以服务端当做四个客户端去处理，那么自动登录成功后，会把服务端的SessionId保存起来，那么下一个请求刚好在自动登录操作之后完成，同样把服务端带来的SESSIONID保存起来，并且覆盖之前的SESSIONID，所以，虽然提示登录成功了，但是登录成功的是那个被覆盖的SESSIONID，你后来所使用的都是最后一个，未登录的那个SESSIONID。

所以才会出现那种，明明提示登录成功，但是去点击其他地方的时候，却提示一个未登录的信息。

解决

OK，知道了原理之后，我们来处理一下，我这里使用的是Retrofit网络请求框架，Cookie的支持，是使用的网上抄来经过自己修改的。

那么，我给我的Cookie框架，增加一个白名单的功能，只有在请求链接是指定的链接的时候，才允许往本地写SESSIONID，否则，是不允许写SESSIONID的，这样子就保证了本地的SESSIONID只会保存自己想要的那个SESSIONID。

我这里给的白名单是，只允许登录，自动登录，注册，三个接口才允许往本地写 SESSIONID，其他的，只有读取的权限。

结尾

这里贴一下经过自己的修改的那个Cookie的GitHub链接：OkHttpHelper:https://github.com/xiaolei123/OkHttpHelper

implementation 'com.xiaolei:OkHttpUtil:1.0.5'

关键文件：CookieJar

使用：

List<URL> list = new ArrayList();
list.add(new URL("http://www.baidu.com/aaa/login.action"));
list.add(new URL("http://www.baidu.com/aaa/autoLogin.action"));
list.add(new URL("http://www.baidu.com/aaa/register.action"));
CookieJar  cookieJar = new CookieJar(Application,);


new OkHttpClient.Builder().cookieJar(cookieJar ).build();

不需要修改Cookie文件的另一种处理方式：

我们这里先了解一下，为什么这种情况为什么在浏览器比如Chrome里不会出现。 那么我们先了解一下Chrome的加载流程： Chrome -> 首页HTML -> JS,CSS,... 也就是说，浏览器在加载的时候，会先加载HTML，这时候会话已经形成，再加载后续的资源文件也好，或者点击上面的链接也好，都依赖第一个请求。

那么我们这里就模仿浏览器的请求，在加载我们关键的文件之前：

APP->启动页（这里加载一个接口） -> 首页（并发加载需要的数据接口）

那么这样子，后续的接口都依赖第一个接口产生的SESSNIONID，也就保证了SessionID的同步。

END。