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

时间:2022-06-01
本文章向大家介绍分析一次自动登录引起的风波,并提供对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。