android app token过期退出登录_退出功能需要网络支持吗？

本文实际上是一道面试题，关于登录主题做一些探讨。

对应功能常见的设计思路，表达能力，易混淆的概念，功能责任的分离，直至网络协议的一些特点，通过这道面试题就可以挖掘出来了。

你在网上是搜不到答案的，只有我跟面试者沟通时才会这么出题。

这道题会涉及以下几个方面

用户状态保存逻辑/常见的软件应用开发中如何存储和维持用户的状态？

更多的应聘者会提到 Token，那么

Token 服务端的设计策略是什么

进而细化为

服务端如何识别用户

回到题目如何理解状态，前后端分离大多采用 HTTP 协议通讯，HTTP 却是无状态的，而我们又要保存用户的状态，矛盾了吧

HTTP 是无状态的，单纯的做请求响应，而业务必须是有状态的，否则业务无法流转和推进。二者是如何关联的
账号体系如何设计的

这样沟通下来是不是一连串的问题都引申出来了？

理解状态

状态的理解实际上很抽象，我们可以 理解为状态就是业务的延续性，有了状态 ，业务才能正常流转。流转实际上是数据的流动，进而状态就是在处理数据。

对无状态的理解核心-独立，【每次请求是独立的，低耦合的】。状态实际上最终是通过数据体现的，有状态就代表着过多的数据依赖。

接口设计最佳实践 文中有以下一句建议

A RESTful API should be stateless

This means that request authentication should not depend on cookies or sessions. Instead, each request should come with some sort authentication credentials.

现在 业界最流行的状态保存维护方案就是 Token 机制。从 cookies 和 session 到 Token，就是技术的演化过程。

思考

客户端 （特指安卓和 iOS 的原生客户端）中有 cookies 和 session 的概念吗？如何理解和阐述

账号系统设计第一要点 登录与退出

既然题目中提到了退出功能，说一说账号系统的设计。

之前产品同事在需求评审中提出一个场景：

公众号链接业务系统登录，用户在业务系统修改密码之后，返回到微信公众号中仍然可以进入需要登录授权才可以访问的页面，没有任何重新登录的提示。

其实原因很简单，微信公众号链接业务系统登录的体系采用的 Token 保存用户信息的两方 OAuth 协议(注意啊这里说的是业务系统本身的登录逻辑，并不是微信开发平台)。

Token 有一个有效时长的生命周期，鉴于减少用户频繁登录的用户体验效果，微信端的 Token 时长会设置的长一些，比如一个月。当在有效时长内，用户修改密码后，实际上微信端的 Token 是感知不到的。

为什么感知不到，从产品的完整度来说，这块是欠缺的，从技术方面来说这要从 Token 的生成和存储谈起。

Token 生命周期由客户端登录场景发起，服务器端负责分配和管理。最常见的存储方式是在 redis 数据库中采用 key value 形式，而 key 是 token， value 是一些需要缓存的热点数据，一般以用户编号，用户名等 profile 信息为主。

账户系统如果设计到这一步，已经可以满足大部分应用系统以云端为中心，多个客户端正常登录的情况了。 这种验证方式也是我上文提到的 宽泛的两方 OAuth 协议的应用。之前有一篇文章单独阐述了两方 OAuth 系统服务化构建-两方 OAuth

接着继续描述，端应用拿着用户的 Token 信息，会对应查找到缓存数据。修改密码后，系统拿到的是用户编号之类的唯一标识。如果在生成 Token 时，没有做用户唯一标识与 Token 的对应关系，那么修改密码后也就关联不到用户已生效的 Token 信息。

两个对应关系，分别是以 Token 为 key，和以用户唯一标识为 key，结合使用就可以实现 Token 的管理

账号系统设计的第二要点 远程管理

我们把接入账号系统的系统都抽象为应用，不管是网站，原生 APP，混合 APP，还是微信小程序。远程管理的用户有两类，一类是云端管理人员，一类是登录用户。

云端管理人员 远程查看用户登录状态，在线统计，多设备管理，踢人，都是这方面的应用场景。

登录用户在个人中心查看个人账号登录过哪些应用，剩余时长如何，实现登录应用退出。如图 2 Teambition 的个人中心。

以上是开放平台授权登录的套路，只涉及到应用服务端和客户端，并没有达到 OAuth 三方角色的复杂度。

远程账号分配，保持，注销，统计

账号系统设计的第三要点 服务化

基于以上两个要点设计完成之后，账号系统已经满足了独立于其它的系统的要求，可以以账号中心的身份自行运转了，其本身就是一个通行证的协调分配中心。我们试着列出如下 FetureList

实名验证

1 验证手机

实现方式 通过发送验证码来验证登录身份

2 多种登录渠道，如手机验证码，用户名密码，微信扫码（第三方账号的一种），手机与密码（用户名登录的一种）

应用授权管理

企业的应用分为内部应用和外部应用

应用列表

退出应用

登录应用

退出所有应用

操作日志

在线人数统计

运营分析

...

安全中心

1 账号信息常规维护，密码修改，找回，登录方式选择

1 密码修改后的登录管理 （单点登录，设备关联，退出已有登录）

2 登录有效时长（由端应用自行控制）

退出功能与网络支持

回到题目中，退出功能与网络支持的产品形态是这样的：

退出功能，请求退出登录接口，服务端注销登录凭据，客户端移除相关本地存储。 有无网络，退出接口是否成功，都以退出成功的交互引导用户，至于其它的，通过技术来实现。如服务端的自动失效等。

常见的误区是，退出只做客户端的凭据删除，然后跳转登录页面，这样的流程过于简单了。

end 2019年12月 公众号 图南日晟