Troubleshooting is a tedious task.

In general, the troubleshooting time usually exceeds the coding time during the process of developing a system. Troubleshooting takes more time to maintain old projects, especially those developed by others.

The CGI website that was maintained some time ago recently has listed n multiple problems under a detailed troubleshooting by the debugging group. Some problems seem to be incredible, but they do exist. A bunch of developers are busy. I have just heard of a reply meeting this morning, and I took over an unusually difficult bug this afternoon.

We know that ASP or ASP. all websites developed by net can use a session to store information related to specific users and set data such as timeout. However, for CGIProgramFor example, there is no such convenience. However, our CGI program has some special requirements. For example, it requires that two identical users cannot use the system at the same time, and the timeout limit must be implemented.

It should be said that the designers of the system were excellent in the past and basically solved these two problems satisfactorily. His idea is as follows: every user opens a page and immediately leaves an access record in the database. This record mainly includes three fields: User ID, IP address, incremental access variable, and a temporary access password. The temporary access password includes the user's authentication password and the user's access time data. When a user logs on, first check the IP address. If the authentication fails, the user must log on again. Then, the system checks the password in the input parameters. If the user logs on from the authentication page, all previous access records of the user are cleared. If not, check the temporary password in the input parameter to see if it matches the last temporary password in the access record. If yes, then check the interval. If the expire setting is expire, the authentication fails.

Basically, this design is perfect. Both timeout and multi-point logon is not allowed for the same account. This is because when a user logs on from the authentication page, all the previous access records will be cleared. That is to say, even if another account that uses the same user is online, he cannot continue to use it, the temporary password is invalid.

However, it is such a design, but it is still found in the test that there are multiple authentication failures. For a long period of time, the test group cannot locate the error accurately or reproduce the error accurately. At first, we thought it was a temporary password that failed to be written to the database. However, in subsequent monitoring, we found that every database operation was completed correctly, but the authentication failure error still appeared randomly. The user authentication function has to be temporarily blocked in the early and middle stages of development.

However, with the approaching of the finfinal delivery date, this problem is becoming more and more urgent. During the test, we found that this problem already exists in the original version, but it is also basically random. CGI program debugging is very troublesome, and this error often does not appear when tracking, but does not appear when tracking, It is very depressing.

Since it cannot be tracked, use logging. Finally, I found a rule in hundreds of dense records: the previous page of the error uses the frame page. Further analysis finally finds out the cause: when using the framework page, different parts of the framework page will have a user authentication process when loading the page, both user authentication processes generate temporary passwords for the next authentication. If one digit is skipped in seconds between the two pages, the calculated password will be different. In this case, the authentication fails. This is not very common, so it is difficult to capture and reproduce.

If you find this cause, it's easy. Only one page can be set in the framework to generate a temporary password, which can solve the problem naturally. Of course, this is not so simple. After several small bugs have been solved, we have finally achieved success.

Think about it later. This CGI program has excellent control over user authentication. When I first understood the basic authentication process, I once thought about why to keep access records successively? Isn't it better to leave only the last record? Later I learned that it was a wise choice to leave a record. At the very least, I provided support for selecting "Back/back" in the browser, because if no access record is left, after the page is rolled back, no authentication is successful.

Now, the CGI project is almost all over, which is really a sigh of relief. If you can choose one, we hope that we will not do CGI any more.