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分钟的修改方式;倒是这样的话我们系统也就不会认为参数超时了,也行吧。