token 后端管理思路

[huangshuwei]

token 后端管理思路

token 的组成
token 的生成包含‘密钥+用户名+Mac 地址+时间戳’，然后通过可逆或者非可逆的加密方式生成token。 其中密钥是由服务端配置的特殊字符串。

token 的生成
前端携带用户名和密码发起登录，服务端验证有效后返回给前端 token。

token 的存储
1、如果token 通过可逆方式生成
不需要存储
2、如果token 通过不可逆的方式生成
需要存储，可以存储到 redis 等缓存服务器或者数据库（不推荐）。如果需要设置有效期还需要存储当前服务器时间。

token 的验证过程
1、如果token 通过可逆方式生成
前端携带token 请求后端服务器，服务器将token 结合密钥进行解密，解密后判断Mac 地址是否一致，不一致则有可能cookie 被盗用，那么返回前端token验证失败；如果Mac 地址符合则将时间戳和服务器时间比较，如果时间没有过期则token 验证成功，继续执行下面的业务逻辑。
2、如果token 通过不可逆的方式生成
前端携带token 请求后端服务器，通过 token 到 redis 等缓存服务器或者数据库中读取 token 和token的存储时间，如果没有获取到 token 信息则返回前端token验证失败；如果获取到了token 信息，则判断token 的存储时间是否过期，如果时间没有过期则token 验证成功。继续执行下面的业务逻辑。

token滑动失效策略
1、如果用户正在提交表单，突然提示‘登录信息已过去，请重新登录！’这种体验肯定是不好的。但是也没办法完全避免，比如token 有效期是1天时间，而用户表单2天后才提交。不过可以减少重新登录的概率，比如token 有效期是1天时间，用户在1天时间内操作去更新用户的最后登录时间，使token 的有效期往后顺延。但是用户的每次操作都去修改用户的最后登录时间也不合适，这里可以做一个策略，比如用户操作大于1小时间隔了再去修改最后登录时间（滑动失效时间修改时间间隔由token的过期时间决定）。
2、这个策略对于token 存储在redis 缓存服务器中的情况很好操作，但是对于token 不存储的方式（可逆的加密方式生成）有一定的困难，因为token 的生成是包含生成时间的，修改了用户的操作时间token 就会改变，这时如果也要做到token滑动失效,需要前端做响应结果处理，即数据的请求的响应结果被统一的处理，如果判断token 验证成功并且token 被修改则前端也对应的去修改token 的存储。

疑问：
客户端Mac 地址获取不到？