2023.4.20

一、前言

最近有个需求，其它系统要通过url跳转到我们组的系统。

于是，就把生成url的方法给了其它系统。

url中主要有：

1.域名，是我们组系统的域名。

2.普通参数，是跳转用的参数。

3.参数t，是个当前时间的时间戳，用来校验参数是否超时。

4.参数sign，是个加密串，是由"普通参数+参数t"组合、用秘钥加密后形成的，用来验证参数是否合法。

正常情况下，其它系统访问生成的url，我们系统会对t和sign进行校验，合法的话就允许继续访问，否则报错，不允许访问。

二、问题

结果，对面系统上线后，发现跳转我们系统时，有时候会报错“参数超时”。

这个就很坑，我们的系统之前也对接过其它系统，都没有发现这种问题，就是这次出了问题。

首先，我们系统近期没有发版，所以问题肯定是对面系统生成的url有问题；

虽然是对面的问题，但是也得协助对面解决。

下面是各种尝试：
1.首先，参数超时这个错误是我们的服务器后台、检查url的参数t报的错。

2.怀疑是服务器系统时间不准导致的，t是获取的服务器系统时间戳，如果自己的和对面的服务器时间不一致，有可能报这个错；
然而检查完服务器时间，没有发现问题。

linux查看时间戳命令：
date +%s

3.怀疑是我们后台代码问题，就梳理git提交记录和发版记录，发现没有改动校验逻辑，近期也没有发版，排除。

4.怀疑是我们提供的url生成方法的问题，就仔细检查了一遍我们提供的java类，也没有发现问题。

5.怀疑是对面在使用我们提供的java过程中有问题，但是由于代码是其它项目组的，我们没有权限查看，只能让他们自查。

最终，我们排查了半天，也没有找到问题，只能让对面把参数t改的大些，确保url不会超时。

PS：这个参数t的作用是，如果生成了一个url，立刻访问，那是没有问题的；
如果生成了一个url，过了一段时间才访问，那java后台就会报错参数超时；
防止生成一个url后就能永久访问的情况发生。

三、后续

2023.4.25
后来，其它系统终于自己找到了问题，是因为他们对参数进行了缓存导致的，缓存时间5分钟；
也就是说，其它系统先生成一个url（此时参数t就固定不变了，是系统当前时间戳），如果立刻访问，是正常的；
也有可能4分59秒后才访问，这样的话我们系统就会报错“参数超时”。

正确的解决方法是，让其它系统不要对这个url进行缓存，访问的时候再立即生成。

不过其它系统不想这么改，选择了把t改大5分钟的修改方式；倒是这样的话我们系统也就不会认为参数超时了，也行吧。