Joint debugging diary: parameter timeout problem

2023.4.20

I. Introduction

Recently, there is a demand that other systems need to jump to our group's system through url.

Therefore, the method of generating url was given to other systems.

The url mainly includes:

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

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

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

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

Under normal circumstances, when other systems access the generated url, our system will check the sum tand signallow continued access if it is legal, otherwise an error will be reported and access will not be allowed.

Two, the problem

As a result, after the opposite system went online, it was found that when jumping to our system, sometimes an error "parameter timeout" would be reported .

This is very tricky. Our system has been connected to other systems before, and we have not found this kind of problem. It is this time that there is a problem.

First of all, our system has not released a version recently, so the problem must be that there is a problem with the url generated by the opposite system;

Although it is a problem facing the other person, it is necessary to assist the other person to solve it.

The following are various attempts:
1. First, the error of parameter timeout is reported by our server background and checking the parameters of the url t.

2. It is suspected that the server system time is inaccurate. t is the obtained server system time stamp. If your own time is inconsistent with the opposite server time, you may report this error; however, after checking the
server time, no problem is found.

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

3. Suspected that it was a problem with our background code, we sorted out the git submission records and release records, and found that the verification logic was not changed, and there was no release in the near future, so we ruled it out.

4. I suspected that it was a problem with the url generation method we provided, so I checked the java class we provided carefully, and found no problem.

5. It is suspected that there is a problem in the process of using the java provided by us, but since the code belongs to other project teams, we do not have permission to view it, so we can only let them check it themselves.

In the end, we checked for a long time, but did not find the problem, so we had to ask the other party to change the parameter t to a larger value to ensure that the url would not time out.

PS: The function of this parameter tis that if you generate a url and access it immediately, there is no problem;
if you generate a url and access it after a while, the java background will report an error 参数超时;
prevent it from being able to A case of permanent access occurs.

Three, follow-up

After 2023.4.25 , other
systems finally found the problem by themselves, because they cached the parameters, and the cache time was 5 minutes ; The current time stamp of the system), if you visit immediately, it is normal; it is also possible to visit after 4 minutes and 59 seconds, in this case, our system will report an error "parameter timeout" .
t

The correct solution is to let other systems not cache this url, and generate it immediately when accessing it.

However, other systems didn’t want to change it like this, so they chose to increase tthe change by 5 minutes; if this is the case, our system will not think that the parameter has timed out, so it’s okay.

Guess you like

Origin blog.csdn.net/BHSZZY/article/details/130409381