Today, I met the problem and studied it. To solve this problem, we must first understand some of the mechanism of the session. Session in the server is in the form of a hash table, we all know that sessions are conversational level, each user access will generate a conversation. So how does the server differentiate between different user sessions and how do you bind different user sessions to different users? Let's look at the following, which is purely my personal understanding, if there is a mistake please testify.
Session on the server side is in the form of a hash table, distinguish each session is through the SessionID to achieve, so it can be said that the SessionID is a key is a globally unique value. We can print out the SessionID by asp.net to the following code:
protected void Page_Load (object sender, EventArgs e)
{
Response.Write (Session.SessionID.ToString ());
}
So we get the value: 0julmoedn0kz3gyfnr1vksv0, a bit like a GUID, even if not the algorithm is similar, mainly to ensure global uniqueness. This achieves the purpose of distinguishing the sessions of different users. Then there is the second question, which is sessionid, but how does it bind to the corresponding visitor (user)? for example, user a access to maintain their own sessionid, User B Access also maintained their own sessionid. We all know that the Web is based on HTTP without links, and how do they do it? Yes, the answer is to store your own SessionID on the client. There are two ways to store SessionID in browsers, one of which is to use cookies, and one is to take advantage of URL parameters (which we don't use very often and are unfriendly).
The topic says cookies come up, what? I didn't think the session and cookies have such a relationship? (A lot of people know, don't bs me) Yes, when we ask for a URL, the server generates a global SessionID, and the value is stored as a cookie in the client is the browser (the URL is not discussed here). So when the user requests again, the HTTP header to the SessionID cookies to the server side, the server to find this SessionID, if found. It proves that the user's status exists.
Know this principle, our problem also has a brow, that is to use cookies to save SessionID, then we can cheat on the cooikes. We all know that Cooikes records are based on domains (for example: http://www.local.com/), which is also required by various browsers. If you do not do this, security will be problematic. All we have to do is to specify the parent domain of the cookie, without specifying the domain, so that the cookies can cross the subdomain. Cookies can specify fields like this:
protected void Page_Load (object sender, EventArgs e)
{
response.cookies["Mycook"]. Domain = ". Local.com";
}
In this way, all of our level two domains are all recognized as the primary domain, such as a.local.com;b.local.com;user.local.com and so on. With this understanding, I think we have a few in mind, how to do, but now the problem is used to generate SessionID method is ASP.net automatic implementation, how do we interfere with it? This is done, do not actively interfere with it, but I can operate its cookies ah. Next, we will study the name of the cooike of the ASP.net deposit SessionID. It's easy to find after the Internet, the name is: Asp.net_sessionid, this is SessionId's cookie name. We can write this in session_start:
protected void Session_Start (object sender, EventArgs e)
{
response.cookies["Asp.net_sessionid"]. Value = Session.SessionID.ToString ();
response.cookies["Asp.net_sessionid"]. Domain = ". Local.com";
}
The meaning of the code is that every time the session starts, I rewrite the Asp.net_sessionid cookie into the sessionid we already have, and specify the domain of the cookie as the parent, for example:. local.com, This enables session sharing across subdomains. How simple is it?