Recently I encountered a serial number problem, that is, after A logs in, when entering a function, I see B's page. Troubled for a lot of time. View the content of the http response header as follows:
Age:1762
Content-Language:zh-CN
Content-Length:25035
Content-Type:text/html;charset=UTF-8
Date:Mon, 28 Mar 2016 01:11:45 GMT
"Age" http header? View the http protocol definition as follows:
The Age response-header field conveys the sender's estimate of the amount of time since the response (or its revalidation) was generated at the origin server. A cached response is “fresh” if its age does not exceed its freshness lifetime.
Is this page cached? Otherwise, the Age header will not be generated. Finally, it was found that the site acceleration function was turned on in the web firewall. After turning off the acceleration function and clearing the cache, the problem was solved.
Turn to an article: http://it.taocms.org/06/791.htm
Speaking of Taobao user serial number, I have two reasons for technical bugs in my impression. In 2010, this serial number lasted for a long time. I estimate that it should exist for a few years. From the Taobao forum, cases broke out every three or five times. xxx suddenly entered someone else's account when visiting my Taobao page. The first feeling was that "all the products that have been bought or sold" are not their own. , and you can perform arbitrary operations on this information, such as deletion and removal.
The other is that Taobao's serial number exploded in November 2012. Suddenly, a seller told me that he had entered someone else's store and could perform arbitrary operations.
There is also a serial number scenario, but it is not caused by a system bug, but mainly because of the serial number caused by the data being cached. This serial number is not a serial number in the true sense, because the page is cached by ISV or a local area network. , resulting in seeing other people's products or stores. In this scenario, users cannot perform any management operations on the pages and data they see.
Generally, in this serial number scenario, we will add a timestamp to the suffix of the url, so that each user's url is different to prevent caching. For example, when generating hyperlinks such as menus, the timestamp is uniformly added.
Due to historical reasons, the URLs of all pages on Taobao end with htm, which are easily mistaken for static pages, so it is not surprising that they are cached. This type of serial number is relatively simple to check, and the problem is relatively easy to determine. The main criterion is that you only see other people's pages, but do not have any operation permissions, and add a parameter such as &id=111 after the url, the page It will be normal immediately.
It is important to talk about the first two serial numbers in
the first two episodes called "serial numbers caused by request exceptions". The reason is that the exception handling is not accurate enough with jboss's tomcat when implementing requests.
The method of Request.java: protected void parseParameters() has a bug , the request parsing parameter may read dirty data, so if the user has this bug when logging in, it is possible to log in to someone else's account.
http://anonsvn.jboss.org/repos/jbossweb/tags/JBOSSWEB_2_0_1_GA/src/share/classes/org/apache/catalina/connector/Request.java
The second case is called "serial number caused by illegal cache", the reason When the shop system "shopsystem" was doing the static transformation, a cache server was pre-positioned, and the server wrongly cached the http header (the header contained setcookie), because the sessionID is stored by the client of the session framework. Created in each system, if the http header is cached, then this sessionID will be stringed into someone else's sessionID. (There is a question here. Before, there was a signature in the cookie to compare whether the value encrypted by the server is consistent with the value encrypted by the server. If it is inconsistent, the cookie and session information will be cleared, and the user will be logged out. Why is this behavior not triggered? According to this scenario , and did not modify the cookie information, but only modified a cookie of sessionID. In theory, the key cookie information on the client side and the information on the server side should be inconsistent)
The troubleshooting period for these two problems is relatively long, because there is no good The method can identify this serial number problem, and it is more difficult to reproduce. Since there is a second serial number, I believe there will be a third and fourth time. So what needs to be done to prevent it? Or there are some solutions that can locate the problem relatively quickly.
In order to solve some things that the serial number has done:
add a value to the cookie to record the signature produced by the key cookie. This signature is a very simple algorithm. Each time a request is made to the server, the session framework code will match the signature. If the value of the signature is consistent with the data obtained by the server, it is considered legal. Otherwise, the session information and cookie information are cleared and the user is allowed to log in again.
Thinking: session serial number
1. Can it be eliminated?
2. Can troubleshooting be made faster? It is expected that once the serial number occurs, it can be easily found and located which system caused it.