ASP. NET shares sessions in different subdomains

Source: Internet
Author: User
Tags dedicated server

I encountered this problem today, so I studied it. To solve this problem, we must first understand the mechanism of some sessions. Sessions exist on the server in the form of a hash. We all know that sessions are Session-level, and a Session is generated for each user access. So how does the server differentiate sessions of different users? How does one bind sessions of different users to different users? The following is my personal understanding. If any error occurs, please testify.

Sessions exist on the server in the form of a hash. Each Session is implemented by SessionID. Therefore, the SessionID is a globally unique Key. We can print the SessionID through ASP. NET, as shown in the following code:

 
 
  1. protected void Page_Load(object sender, EventArgs e)  
  2.         {  
  3.   Response.Write(Session.SessionID.ToString());  
  4.         } 

In this way, we get the value 0julmoedn0kz3gyfnr1vksv0, which is a bit like GUID. Even if it is not an algorithm, it is similar, mainly to ensure global uniqueness. This achieves the goal of distinguishing sessions of different users. The second problem is that SessionID is available, but how does it bind with the corresponding visitor user? For example, user A's access maintains its own SessionID, and user B's access also maintains its own SessionID. We all know that the web is based on http without links. How do they achieve this? Yes, the answer is to store your SessionID on the client. There are two ways to store SessionID in the browser, one is to use Cookies, and the other is to use url parameters (this is not commonly used and unfriendly ).

The topic is about Cookies. Why? I didn't expect the relationship between Session and Cookies? (Many people know, Don't BS me) Yes. When we request a URL, the server will generate a global SessionID, and save the value in the form of Cookies on the client, that is, the url method is not discussed here in the browser ). In this way, when the user sends the Cookie of the SessionID to the server in the http header, the server will find the SessionID if it finds it. This proves that the user's status exists.

With this principle in mind, we have a frown. Even if we use Cookies to save SessionID, we can do it on Cooikes. We all know that the Cooikes record method is distinguished by the domain (for example: http://www.local.com/), which is also stipulated by various browsers. If this is not done, security issues may occur. What we need to do is to specify the cookie parent domain instead of the specific domain, so that Cookies can be cross-subdomains. Cookies can specify domains like this:

 
 
  1. protected void Page_Load(object sender, EventArgs e)  
  2.        {  
  3. Response.Cookies["MyCook"].Domain = ".local.com";  
  4.        } 

In this way, all our second-level domains recognize this primary domain, such as a.local.com, B .local.com, and user.local.com. With this understanding, I think everyone knows how to do it, but now the problem is that ASP is used to generate SessionID. NET automatically implemented, how do we interfere with it? This is done in this way and does not actively interfere with it, but I can operate on its Cookies. Next we will study the name of the Cooike with SessionID stored in ASP. NET. It is easy to find it on the Internet. The name is ASP. NET_SessionId, which is the cookie name of SessionId. We can write in Session_Start as follows:

 
 
  1.  protected void Session_Start(object sender, EventArgs e)  
  2.         {  
  3. Response.Cookies["ASP.NET_SessionId"].Value = Session.SessionID.ToString();  
  4.  Response.Cookies["ASP.NET_SessionId"].Domain = ".local.com";  
  5.         }  

The code means that at the beginning of each session, I put ASP. the Cookie NET_SessionId is rewritten to our existing SessionID, And the Cookie domain is specified as the parent domain, for example, .local.com. This allows cross-subdomain Session sharing. How easy is it?

We have another problem, that is, the client saves the problem, but what should we do with the server Session? Generally, different subdomains direct to different servers. For example, user.local.com is a dedicated server and yellow.local.com is a dedicated server. In this case, they are not processes, and they are not physical. How to share sessions? In this case, another method is used. The default Session is stored in the asp.net process, and mutual access is not allowed, as shown below:

 
 
  1. <sessionState mode="InProc" /> 

We can change it to the State Server mode. This is a separate service that can be used to store ASP. NET Session, which supports distributed remote hosts, so that we can use a server to provide the Session service, as shown below:

 
 
  1. <sessionState mode="StateServer" stateConnectionString
  2. ="tcpip=127.0.0.1:42424" timeout="30" /> 

In this way, the Session sharing of different subdomains is fully realized.

As mentioned above, the method of saving SessionId by Url is not commonly used. Let's demonstrate the following Configuration:

 
 
  1. <sessionState mode="StateServer" stateConnectionString=
  2. "tcpip=127.0.0.1:42424" timeout="30" cookieless="true" /> 

The cookieless attribute specifies whether to use cookies to save the SessionId. Run the following command to get the result:

Http: // localhost: 3380/(S (dqxcs455n4u2vg55ia51fvqg)/default. aspx

Original article title: Share Session in different subdomains in ASP. NET

Link: http://www.cnblogs.com/assion/archive/2010/07/29/1787960.html

Related Article

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.