Shulou(Shulou.com)06/02 Report--

There was a serious accident in our APP production. Many users complained that they could see other people's information after logging in. After receiving the complaint, we began to look for the problem. Generally, such problems are caused by thread safety, so the idea of finding the cause is to check according to the thread safety idea.

The business scenario is that after the user logs in, click on a page to view the information, which shows the information of others.

The general process of logging in to the deal is as follows:

/ / A series of verification session.setAttribute ("id", id); / / put the document number into session// other operations

The process for viewing information transactions is as follows:

Session = request.getSession (); if (session! = null & & session.getAttribute ("LoginStatus") = = True) {String id = session.getAttribute ("id"); Information info = queryInfo (id); return info;} else {return "not login";}

By adding logs and other methods, we confirmed that when we checked the information, the ID number taken out of the session belonged to someone else, but when it changed, we couldn't find it, because we have been following the thread-safe way of thinking, looking for places like global variables.

Another suspicious thing is that there is an asynchronous thread that validates the user's ID number and replays it in the session.

Public void updateId (HttpServletRequest request) {HttpSession session = request.getSession (); String id = validate (); session.setAttribute ("id", id);}

This function is handled in the thread pool set up by logging in to the main transaction, and it doesn't seem to have much trouble, and it's the old code for a long time. And I found a rule that the login transactions of users who saw the information by others triggered to log in with the new device, because we added a logic to verify the login of the replacement device, so we need to verify the SMS message, and the login is divided into two steps. the first step is returned quickly, but the asynchronous update information process is still there.

So I wonder if it's because the Servlet transaction has been returned, and the asynchronous thread gets the HttpServletRequest, but the request is invalid or reused.

I wrote the following code for verification and kept calling it with curl. The Http request will be returned soon, but I will pass the HttpServletRequest to a thread pool and wait 5 seconds before processing the Request. As a result, there is a problem.

As a result, there is a problem. In most cases, the new_session is null, but there is also a situation that it is not null. At this time, I find that session is not my own.

HttpServletRequest has a lifecycle. When a http request comes, the application server parses the message, puts various parameters in a HttpServletRequest object, and then passes them to the service function of Servlet. The service function calls the corresponding doGet/doPost and other methods according to the methods in it. Once the service function call ends, the lifecycle of HttpServletRequest ends. After that, you continue to use this object, and the result is uncertain.

There are not many people who encounter this kind of problem on the Internet. I specifically found servlet specification, and there is a chapter on the life cycle of HttpServletRequest.

The following information can be obtained from it:

(1) request is valid in three cases: asynchronous thread initiated by startAsync within service function, within doFilter function

(2) in addition to three cases, the use of request will produce uncertain results (indeterminate results)

(3) when implementing servlet, most containers reuse request objects in order to improve performance, but this is not necessary in the specification.

The startAsync mentioned in this article begins with servlet 3.0.It is designed to allow a worker thread to do other things when doing IO or similar blocking thread operations, but it requires that the asynchronous thread ends before it returns the request to the client, which is essentially synchronous, just parallel. So if you want to deal with Request asynchronously, you must use servlet's own asynchronous mechanism, but this does not meet our needs, because we are trying to keep the main thread from waiting.

Usage example:

If this is used, the client needs to wait 5 seconds to get the results.

I looked at the source code of tomcat and found that it did reuse Request:

Although the cause of the problem is simple, the consequences are very serious. Be very careful when you need to process data asynchronously. It's okay to send Session here, but try to avoid it.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.