Flutter 入门与实战(三十二):小伙子,你买票了吗?

2,820 阅读5分钟

前言

话说那时候还是学生,有一年春运,冒着风雪在北京北站买回家的票。悲催的是,特快车的票没买着,只买到了绿皮火车,L 打头的临时车。更悲催的是,原本33个小时的车程(特快不到20个小时),结果……走走停停超过了40多个小时,那煎熬,感觉永无尽头!

image.png image.png

换个别的方式吧!于是我提前下车了,下车到了出站口,车站检票人员瞄了一眼我的车牌,眼神有点奇怪,估计是在想这小伙子是不是傻。还好我的票到站点是更远的站,不需要补票。其他没票的,就被嚷嚷着补票了——那个时候为了能回家,多少人是偷偷混上车的啊! 以前是一把心酸一把泪,现在回忆起来那都是年少时难得的经历啊!

image.png

火车票与会话

火车票就好像我们后台的会话 Session一样,坐火车的这个过程就是我们的会话过程。我们需要先买票才能上车,下车出站票就失效了。本篇我们就来介绍Dio如何使用会话Session保持登录状态。首先请更新后台代码:gitee.com/island-code…,涉及到的接口如下:

先拿 Postman 走一遍流程做一下接口自测(我们的口号是真正的全栈:产品->设计->后端->前端->测试->运维一条龙服务)。过程见下图:

屏幕录制2021-07-21 下午9.32.35.gif 可以看到整个会话过程如下:

  • 登录成功后,后端会返回 Cookie,对应的是一个 sessionId 字段(字段名由后端定),这里就是登录人的会话信息。
  • 每次请求相同域名的接口时候,Postman就会携带这个 Cookie 到后端,从而实现了会话过程的免登录验证。
  • 如果退出登录,后端会清除会话信息,此时携带原有的会话信息请求会被后端认为是无效的。

这个过程对于我们使用 Postman 是无感知的,就好比我们用浏览器访问网页一样。但是对于 App 来说就不一样了。App本身是不会自动把登录会话信息携带到其他接口的,也就是说如果我们登录成功后不做会话处理,那么其他涉及到需要会话信息的接口全部会失败!这就好比我们买了张火车票,但是弄丢了,傻乎乎地跑到检票口才发现进不了站!!!

携带会话信息

怎么办?首先是在买票环节我们要把票保存好,在我们的 HttpUtil 中找一个严实的口袋保存车票,这个口袋就是 Dio 的 options.headers。当我们往 options 里存放信息时,每次请求都会携带这些信息到后端(除非请求本身将其参数覆盖)。

static void setCookie(String cookie) {
  _dioInstance.options.headers['Cookie'] = cookie;
}

options 是 Dio 的默认请求配置,是一个BaseOptions对象,包括了很多属性,例如请求方法、响应类型、请求内容类型,连接超时时间、默认查询参数、请求头等等,通过设置 options 我们可以设置很多默认的参数,从而避免到处设置。常见的设置有:

  • 连接超时:connectTimeout,可以根据需要设置超时时长。
  • 请求内容类型:contentType,是一个字符串,默认是:application/json; charset=utf-8。可以在 headers 里设置也可以指定。
  • 响应类型:responseType,是一个枚举,默认是 json
  • 默认查询参数:queryParameters,一个Map 对象,假设接口有默认的请求参数(如终端类型,版本号这类)可以加入到这里。
  • 请求头:headers,也就是我们今天的主角,可以设置请求的 cookie 信息或者其他参数(比如 JWT 的 token,后端要求传递的其他通用参数)。其中 cookie 固定使用 Cookie 字段存储,当然如果后端要自定义别的字段也是可以的。

找着了口袋,我们买完票后就需要把票存放起来,也就是登录成功后要获取到后端设置的 cookie,这个是在响应头里,调试的时候可以打印出来整个 headers 查看,如下所示:

image.png

实际 cookie 存在response.headers.map['set-cookie']中,注意这是一个数组,我们这里因为只有一个 cookie,因此取第一个元素再调用 HttpUtilsetCookie即可。登录处理业务逻辑如下:

_handleSubmit(String username, String password) async {
  EasyLoading.showInfo('请稍候...');
  var response = await AuthService.login(username, password);
  if (response != null && response.statusCode == 200) {
    EasyLoading.showSuccess('登录成功');
    if (response.headers.map['set-cookie'] != null) {
      HttpUtil.setCookie(response.headers.map['set-cookie'][0]);
    }
    Navigator.of(context).pop();
  } else {
    EasyLoading.showInfo(response.statusMessage);
  }
  EasyLoading.dismiss();
}

这样,主要我们不退出登录,我们就可以携带会话信息与后端友好地交互了——碰到查票的你也不用心慌了!

image.png

清除会话信息

下车了,以前票默认是要回收的,可千万别只是返回到登录页面哦!退出登录时 调用后端的退出登录接口,成功后需要清除掉本地的存储的sessionclearCookie方法很简单,只是将 headersCookie 设置为 null 即可。

void _logout() async {
  var response = await AuthService.logout();
  if (response != null && response.statusCode == 200) {
    HttpUtil.clearCookie();
    EasyLoading.showSuccess('已退出登录');
  } else {
    print('logout Failed');
  }
}
static void clearCookie() {
  _dioInstance.options.headers['Cookie'] = null;
}

验票

有了这个,我们就可以像乘务员那样验票了。验票这里只是调用了后端的一个需要会话信息的接口来验证。

void _checkSession() async {
  var response = await AuthService.checkSession();
  if (response != null && response.statusCode == 200) {
    print(response.data);
    EasyLoading.showSuccess('验票通过,持票人:' + response.data['loginUser']);
  } else {
    print('Request Failed');
  }
}

运行效果如下图:

屏幕录制2021-07-21 下午10.18.33.gif

总结

本篇介绍了 Dio如何在登录后携带会话信息,以避免其他需要登录鉴权的接口请求失败。需要注意的是,会话信息在退出登录后需要及时清除,同时,会话信息可能还携带失效时间信息,可以根据失效时间来判断是否需要重新登录。另外,Dio官方推荐的 Cookie 管理插件是dio_cookie_managerdio_cookie_manager使用拦截器来管理 Cookie,支持使用 CookieJar 来在内存存放 Cookie,或使用 PersistCookieJar持久化Cookie。