春节前最后一天班，解决了困扰将近一周的问题，开心

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

已注册用户请登录

这是一个创建于 73 天前的主题，其中的信息可能已经有所发展或是发生改变。

第 1 条附言 2 月 10 日

spring gateway 网关中加了一个过滤器，并且把一个多余的过滤器删除掉了。结果远程测试打死都过不了时间校验验证代码：
try {
String value = PuzzleSolver.unPuzzle(x_token);
log.info("解密结果, x_toke = {}, value = {}, userinfo = {}", x_token, value, userInfo);
long time = Long.parseLong(value.substring(0, 13));
long start = System.currentTimeMillis();
difference = start - time; // 计算时间戳差值
log.info("{} time diff {},{},{}",requestId,start,time,difference);
} catch (Exception e) {
log.error("解密请求加密出错, x_toke = {}, userinfo = {} ,err:", x_token, userInfo, e);
throw new BusinessException(ErrorEnum.UNAUTHORIZED);
}
if (difference < 0 || difference > 10000) {
log.error("校验请求时间不合法, x_toke = {}, userinfo = {},difference={}", x_token, userInfo, difference);
throw new BusinessException(ErrorEnum.UNAUTHORIZED);
}

成都团队都没问题，就远程测试存在问题，difference 永远小于 0 ，而且因为是网关会影响其他需求测试，导致只能在快下班的时候和测试复现排查问题，断断续续搞了一周吧。今天直接把删除的代码还原了就可以了，最终定位是在删除的代码里存在：exchange.getResponse().getHeaders().add(HeaderConstant.PAYMENT_TIMESTAMP_KEY, String.valueOf(System.currentTimeMillis()));
前端会根据服务器返回的时间搓进行时间校准。

一开始一直是一位是是添加的 Filter 的顺序导致其时间不对，所以方向一直是在优化 Filter 的执行顺序上。

第 2 条附言 2 月 10 日

远程测试使用的是 window 电脑，成都本地团队配置的是 mac pro

春节

问题

23 条回复 2026-02-10 22:39:45 +08:00

wandehul

2 月 10 日

妈的，谁点进来谁傻 b ，来骂一句再走吧。

zenfsharp

2 月 10 日

羡慕 OP 可以把问题拖一个周。
换成我这，第二天就得问我解决了没。

prefect

2 月 10 日

临近下班的时候发现问题没解决，刚思路错了哈哈哈哈

YuzukiYukari

2 月 10 日 via Android

快进到出重大生产事故，大年三十被拉回公司加班

Ghostsss

2 月 10 日

等后续

no2cat

2 月 10 日

做得越多，错的越多。

L0L

2 月 10 日

我就是那个点进来的傻逼

eii

2 月 10 日

没了吗,再发说说呢?

newaccount

2 月 10 日

直说结果不描述问题
纯标题党！
画小圈圈诅咒你回家路上接到紧急 bug

NillSpake

2 月 10 日

画小圈圈诅咒你回家路上接到紧急 bug

unclejoker

2 月 10 日

画小圈圈诅咒你回家路上接到紧急 bug

queifa

2 月 10 日

@zenfsharp 主要本地和在成都的团队都没问题，就远程的测试有问题。而且只是部署了我的代码有问题，部署 main 分支代码他又没问题了。

queifa

2 月 10 日

@newaccount 我的我的，纯粹想分享下喜悦。这里具体说说吧：就是在 spring gateway 网关中加了一个过滤器，并且把一个多余的过滤器删除掉了。结果远程测试打死都过不了时间校验验证代码：
try {
String value = PuzzleSolver.unPuzzle(x_token);
log.info("解密结果, x_toke = {}, value = {}, userinfo = {}", x_token, value, userInfo);
long time = Long.parseLong(value.substring(0, 13));
long start = System.currentTimeMillis();
difference = start - time; // 计算时间戳差值
log.info("{} time diff {},{},{}",requestId,start,time,difference);
} catch (Exception e) {
log.error("解密请求加密出错, x_toke = {}, userinfo = {} ,err:", x_token, userInfo, e);
throw new BusinessException(ErrorEnum.UNAUTHORIZED);
}
if (difference < 0 || difference > 10000) {
log.error("校验请求时间不合法, x_toke = {}, userinfo = {},difference={}", x_token, userInfo, difference);
throw new BusinessException(ErrorEnum.UNAUTHORIZED);
}

成都团队都没问题，就远程测试存在问题，difference 永远小于 0 ，而且因为是网关会影响其他需求测试，导致只能在快下班的时候和测试复现排查问题，断断续续搞了一周吧。今天直接把删除的代码还原了就可以了，最终定位是在删除的代码里存在：exchange.getResponse().getHeaders().add(HeaderConstant.PAYMENT_TIMESTAMP_KEY, String.valueOf(System.currentTimeMillis()));
前端会根据服务器返回的时间搓进行时间校准。

一开始一直是一位是是添加的 Filter 的顺序导致其时间不对，所以方向一直是在优化 Filter 的执行顺序上。

queifa

2 月 10 日

@wandehul 我的我的，纯粹想分享下喜悦。

newaccount

2 月 10 日

@queifa #13 所以，前端校准防作弊是一方面
为啥这个时间会对不上？
如果只考虑小误差，要不你把 diff 取个 abs 试试？

queifa

2 月 10 日

@newaccount window 系统问题吧，前端传过来的时间比服务器上的时间慢了几秒钟。diff 用 abs 按理来说也是可以的，但是领导不同意这种方案呀，可能会存在重放攻击。

newaccount

2 月 10 日

@queifa #16 老哥，你这个是前端比服务器时间快了几秒
从判断上看，如果时间不同步，那么快慢都是有可能的，代码里只检查了慢 10 秒的情况，所以我觉得应该取 abs 把快的情况也加进去，本身你后面的 10 秒检查并没有很好的处理重放

queifa

2 月 10 日

@newaccount 是慢吧，当前时间减去某个时间为负数哦。
long time = Long.parseLong(value.substring(0, 13)); // 前端传的时间搓
long start = System.currentTimeMillis(); // 服务器时间搓
difference = start - time; // 计算时间戳差值

difference < 0 表示服务器时间比前端传递时间快,报错
difference > 0 表示服务器时间比前端传递时间慢

0 <= difference <= 10000,允许服务器时间比前端传递时间慢

newaccount

2 月 10 日

@queifa #18 有图有真相
diff < 0 == start - time < 0 == start < time
---- start ---- time ---->时间方向
---- 服务器时间 ---- 前端时间 ---->时间方向
服务器比前端慢了 == 前端比服务器快了

queifa

2 月 10 日

@newaccount 对的，我搞混了