1.Token简介
-
Token的引入：
当项目要求进行前后端分离或移动端开发时，是无法使用 Session 的，那么需要使用 Token 进行 session 的管理，通过搭建一个认证（Auth）系统负责用户身份验证，并进行整个系统 Token 的维护与管理
-
Token的定义：
Token是服务端生成的一串字符串，以作客户端进行请求的一个令牌，当第一次登录后，服务器生成一个Token便将此Token返回给客户端，以后客户端只需带上这个Token前来请求数据即可，无需再次带上用户名和密码。
-
使用Token的目的：
Token的目的是为了减轻服务器的压力，减少频繁的查询数据库，使服务器更加健壮。
2.Token的数据结构及内容
-
Key：token
其设计原则：必须保证在整个系统中唯一存在 根据不同客户端(PC、移动)，为了便于统一管理和维护，token生成算法设计如下：
- PC 端：token:PC-USERCODE[加密]-USERID-CREATIONDATE-RONDEM[6 位]
- 移动端：token: MOBILE-USERCODE[加密]-USERID-CREATIONDATE-RONDEM[6 位]
-
Value：存储登录用户的信息数据（数据格式为 json）
具体内容包括：ID，账号，用户名，密码，用户类型，平台ID等
3.Token 有效期的维护
基于系统的安全性考虑，需要设置 Token 的有效期，并且为了维护 Token 的有效期，须把 Token 放入到 Redis 里进行维护管理。对于不同客户端（PC 端、移动端）的 Token 所设置的有效期策略不同：
-
PC端
Token 的有效期为 2 个小时，若 2 个小时内没有进行 Token 置换的话，就会自动在 Redis 里清除该 Token，那么当该用户再次发送请求时，则会提示：Token 失效，请重登录。此处应注意：前端须自行管理 Token 的生命周期，原因是 Token 存在 cookie 里，web的安全性较差。
-
移动端
Token 永不失效，修改密码后须更换 Token。 注意：由于移动端的 Token 一般不需要过期，只有当在 PC 页面进行个人密码修改后，移动端才会退出重登录，或者当在移动端修改密码操作，用户也不需要退出重登录，直接在 Redis 中更新该 Token 中用户修改的新密码即可。
4.AS 系统(Auth System)
该系统主要负责登录用户身份的验证，登录成功后生成唯一的 Token，并将 Token 存入到 Redis 里进行维护管理，以及 Token 的置换（Reload）等
生成Token
当用户进行系统登录时，Auth 系统会进行用户名和密码的校验，验证成功后生成 Token，存入到 Redis 中，同时将该 Token 的 key 返回给前端，前端调用的所有 API 都必须传递该 Token，并规定 Token 统一放在请求头（header）里，后端需要获取当前用户信息时，就可以直接从 header 中获取即可。 为了保证绝对的安全，正常业务下的 API 返回给前端的 Token 信息如下：
{
"status":"200",
"data":{
"token":"token:PC-3066014fa0b10792e4a762-23-20170531133947-4f6496",
"ticket":"yhe736dyfhfyw",
"expTime":"6474783",
"genTime":"7565746"
},
"errorcode":"0",
"msg":{}
}
通常情况下返回给前端的 Token 数据只有四项内容：token(key)、ticket、Token 的生成时间、Token 的失效时间。为了安全考虑，不会包含当前用户的任何信息，每次后端需要获取Token 信息时，应从 header 中获取到 token(key)和 ticket，通过它们两个去 Redis 中进行 k-v 匹配获取相应的 Token 信息，即：当前用户的相关信息。
Token 置换
Token 置换规则定义：前端获取 Token 的 1.5 时后可进行 Token 置换，若在最后的半个小时内，客户端发出请求，则会进行 Token 置换，拿到重新生成的 Token（包括：token(key)、生成时间、失效时间），若客户端在最后的半个小时内没有发送任何请求，那么两个小时后自动过期，即：该 Token 自动从 Redis 里清除，用户须重新登录。
注意事项：
- 不论是最后半个小时的置换时间还是 Token 的 2 个小时有效期，都是根据系统的业务需求所设计的策略方案。
- 为了防止客户端恶意的进行 Token 置换，需要保证生成 Token 后的 1 个小时内不允许置换。
- 需要保证客户端传递有效的 Token 进行置换。
- 为了解决页面的并发问题，在进行置换 Token 时，生成新 Token，但是旧 Token 不能立即失效，应设置为置换后的时间延长 2 分钟。否则会出现页面因为 Token 失效而无法完成置换。
编写token置换模块
- 在exception文件夹下，创建TokenValidationFailedException，编写构造方法
public TokenValidationFailedException(String msg) {
super(msg);
}
-
理清置换token编写思路：
-
首先判断token是否有效
-
生成token后的一个小时内不允许置换
-
置换token，需要生成一个新的token，并且旧token不能立即失效，应设置为置换后时间延长两分钟
-
兼容手机端和pc端
-
在TokenService中添加旧token延迟时间
/**
* 旧token延迟时间
*/
public final static int REPLACEMENT_DELAY = 2*60;
- 在TokenService中编写token置换方法
/**
* 置换token
* 1,首先判断token是否有效
* 2，生成token后的一个小时内不允许置换
* 3，置换token，需要生成一个新的token，并且旧token不能立即失效，应设置为置换后时间延长两分钟
* 4，兼容手机端和pc端
*/
//引入logger
private static Logger logger = Logger.getLogger(ItripUserServiceImpl.class);
@Override
public String replaceToken(String agent, String token) throws TokenValidationFailedException {
//1,首先判断token是否有效
if (!exists(token)){
//终止置换
throw new TokenValidationFailedException("未知的Token或Token已过期");
}
Date tokenGenTime;//生成时间
try{
//2，生成token后的一个小时内不允许置换
String[] tokenDetails = token.split("-");
SimpleDateFormat format = new SimpleDateFormat("yyyyMMddHHmmss");
tokenGenTime = format.parse(tokenDetails[3]);
} catch (ParseException e) {
e.printStackTrace();
logger.error(e);
throw new TokenValidationFailedException("token格式错误"+token);
}
long passed = Calendar.getInstance().getTimeInMillis()-tokenGenTime.getTime();
if (passed < REPLACEMENT_PROTECTION_TIMEOUT * 1000){
throw new TokenValidationFailedException("token处于置换保护时间，剩余"+
(REPLACEMENT_PROTECTION_TIMEOUT)*1000+"(s),禁止置换");
}
// 3，置换token，需要生成一个新的token，并且旧token不能立即失效，应设置为置换后时间延长两分钟
String newToken = "";
ItripUser itripUser = this.load(token);
long ttl = redisAPI.ttl(token);//token有效时期
//4,兼容手机端和pc端
if (ttl > 0 || ttl == -1){
newToken = this.generateToken(agent,itripUser);
this.save(newToken,itripUser);
redisAPI.set(token,REPLACEMENT_DELAY,JSON.toJSONString(itripUser));
}else {
throw new TokenValidationFailedException("当前token的过期时间异常，禁止置换");
}
return newToken;
}
- 添加TokenController，引入tokenService，并编写置换token方法retoken
@Autowired
private TokenService tokenService;
@RequestMapping(value = "/retoken",method = RequestMethod.POST,produces = "application/json")
@ResponseBody
public Dto retoken(HttpServletRequest request){
String agent = request.getHeader("user-agent");
String token = request.getHeader("token");
try {
String newToken = tokenService.replaceToken(agent, token);
ItripTokenVo itripTokenVo = new ItripTokenVo(Calendar.getInstance().getTimeInMillis()+ TokenService.SESSION_TIMEOUT*1000,
Calendar.getInstance().getTimeInMillis(),newToken);
return DtoUtil.returnDataSuccess(itripTokenVo);
} catch (Exception e) {
e.printStackTrace();
return DtoUtil.returnFail(e.getMessage(), ErrorCode.AUTH_AUTHENTICATION_FAILED);
}
}
- 启动tomcat，登录爱旅行，在redis中会有当前用户的token，使用postman可以测试，如测试结果msg返回‘token处于置换保护时间，剩余3600000(s),禁止置换’，则正常
5.前/后端具体实现
后端
Auth 系统需要提供 API ：
-
生成 Token
该接口返回的数据内容包括：Token 的 key（注：需要对敏感信息进行加密处理）、 Token 的生成时间、Token 的失效时间（注：过期时间减去生成时间一定是两个小时）
-
Token 置换
该接口返回新 Token。实现过程中需要注意如下几点：
生成 Token 后的 1 个小时内不允许置换（注：主要是为了防止客户端恶意的进行 Token 置换）
由于需要保证客户端传递的置换 Token 为真实存在并有效的，故需要在该API 方法内首先判断 Token 是否有效。
在进行置换 Token，生成新 Token，旧 Token 不能立即失效，应设置为置换后的时间延长 2 分钟。
前端
-
登录成功后，接收 Token 放入 cookie 中，请求的时候从 cookie 中取出放入到 header 里，如下：
$.ajax({ headers:{ Accept:"application/json;charset=utf-8", Content-Type:"application/json;charset=utf-8", //从 cookie 中获取 token:"token:PC-3066014fa0b10792e4a762-23-20170531133947-4f6496" }, type："post", ..... }) -
负责服务器时间同步（根据 API 返回的 Token 生成时间、失效时间进行同步）
-
置换 Token 需要同步处理，即：保证只有一个请求置换 Token
扫一扫
1848
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
