登录

后台前端设计

发起登录/获取用户数据

• 前端率先判断是否登录(非必须)

实际上，在渲染页面时，先经由路由逻辑。所以第一次获取时机肯定在路由层面进行，可以考虑放在 router.beforeEach 中。前端在此时率先判断缓存中是否有 token，没有直接跳转登录页。

• 后端判断登录是否失效

请求可放置在初始化调用的 common.js 或 commonLayout 里

全局用户数据

• 未判断完登录情况/未获取到全局用户数据前，会有一小段空白时间，需要用 loading 填补；或也可以提前缓存一份用户数据到 localStorage 里，先展示缓存数据

未登录自动跳转

• 通用请求库处理

多个后台抽离登录组件

• 前提：抽离 request 库
• 抽离 login 库及登录页，处理登录判断、登录、退出的逻辑
• 抽离展示用户数据的 HeaderLayout

登录失效

• 比如离开太久，前端弹窗需重新输入密码（输入后走普通登录逻辑）: 可以和后端保持一个心跳连接

后端设计

基本概念

Authentication(账密登录) 与 Authorization(后续的自动登录)

SSO: Single Sign On

Cookie-Session 模式（或token存放服务端模式）：

• 会话信息存至内存/redis中

• 如果二级域名相同，那 cookie 还可以共享。如果是多域名，如何实现单点登录呢？可以多域名跳转间携带token

JWT(json-web-tokens) Token（或token存放客户端模式）:

• 本身就包含了用户信息
• 解决的问题：不用读取数据库的用户信息、分布式服务可以各自解析
• 缺陷：无法在服务端销毁，因此无法在到期前主动 invalidate （比如需要黑名单、用户角色变化
• RefreshToken: refreshToken 的策略（ref）这样 access-token 的失效时间可以设短一些

在微服务系统中，也有结合使用的情况：

用户->网关走cookie-session, 网关转发到各领域微服务走 jwt（此时在内部传递的是 JWT 凭证，而非 JWT token）