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

This topic created in 266 days ago, the information mentioned may be changed or developed.

Supplement 1 · Feb 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 的执行顺序上。

Supplement 2 · Feb 10

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

春节

问题

23 replies • 2026-02-10 22:39:45 +08:00

wandehul

Feb 10

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

zenfsharp

Feb 10

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

prefect

Feb 10

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

YuzukiYukari

Feb 10 via Android

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

Ghostsss

Feb 10

等后续

no2cat

Feb 10

做得越多，错的越多。

L0L

Feb 10

我就是那个点进来的傻逼

eii

Feb 10

没了吗,再发说说呢?

newaccount

Feb 10

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

NillSpake

Feb 10

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

unclejoker

Feb 10

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

queifa

Feb 10

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

queifa

Feb 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

Feb 10

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

newaccount

Feb 10

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

queifa

Feb 10

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

newaccount

Feb 10

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

queifa

Feb 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

Feb 10

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

queifa

Feb 10

@newaccount 对的，我搞混了😂

rainbowGeek

Feb 10

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

lowman

Feb 10

写日记？祝你们公司的服务器大年初一集体宕机。

frank4liuyang

Feb 10

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