从火车票验票来说 Flutter 的网络请求会话管理

前言

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

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

火车票与会话

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

• 注册新用户接口：http://localhost:3900/api/users，自行注册一个用户验证。

• 登录接口：http://localhost:3900/api/auth/login，登录成功后会将 Session 写入 Cookie。

• 退出登录接口：http://localhost:3900/api/auth/logout，退出成功后会清除后端 Session。

• 验证会话接口：http://localhost:3900/api/auth/check，检查登录会话是否有效。

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

可以看到整个会话过程如下：

• 登录成功后，后端会返回 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 查看，如下所示：

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

_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();}

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

清除会话信息

下车了，以前票默认是要回收的，可千万别只是返回到登录页面哦！退出登录时 调用后端的退出登录接口，成功后需要清除掉本地的存储的session。clearCookie方法很简单，只是将 headers 的 Cookie 设置为 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');  }}

运行效果如下图：

总结

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