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

This article focuses on "how to share Session in different subdomains in ASP.NET". Interested friends may wish to have a look at it. The method introduced in this paper is simple, fast and practical. Let the editor take you to learn how to share Session in different subdomains in ASP.NET.

The copy code is as follows:

Protected void Page_Load (object sender, EventArgs e)

{

Response.Write (Session.SessionID.ToString ())

}

So we get this value: 0julmoedn0kz3gyfnr1vksv0, which is a bit like GUID, even if not the algorithm is similar, mainly to ensure global uniqueness. This achieves the purpose of distinguishing the Session of different users. Then there is the second question, which is that SessionID has it, but how does it bind to the corresponding visitors (users)? For example, user An access maintains its own SessionID, and user B access maintains its own SessionID. We all know that web is based on http without links. How do they do it? Yes, the answer is to store your own SessionID on the client side. There are two ways for browsers to store SessionID, one is to use Cookies; and the other is to use the url parameter (which we don't use very often and are very unfriendly).

When it comes to Cookies, what's wrong? You didn't expect Session and Cookies to have such a relationship, did you? (many people know, don't BS me) Yes, when we request a URL, the server will generate a global SessionID and save this value in the form of Cookies in the client, that is, the browser (we won't talk about url here). In this way, when the user requests again, the Cookie of the SessionID is sent to the server in the http header, and the server goes to find the SessionID if it is found. It proves that the user's status exists.

Knowing this principle, our problem will be frowned on, that is, using Cookies to save SessionID, then we can tamper with Cooikes. We all know that Cooikes recording is based on domain (for example: https://www.jb51.net/)), which is also specified by various browsers. If you don't do this, there will be security problems. What we need to do is to specify the parent domain mode of the Cookies, without specifying the specific domain, so that the Cookies can span the child domain. Cookies can specify a domain like this:

The copy code is as follows:

Protected void Page_Load (object sender, EventArgs e)

{

Response.Cookies ["MyCook"] .Domain = ".jb51.net"

}

In this way, all of our secondary domains recognize this primary domain, such as a.jb51.netterb.jb51.netwitteruser.jb51.net, and so on. With this understanding, I think we all know what to do, but now the question is that the method used to generate SessionID is automatically implemented by ASP.NET, how can 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 that ASP.NET stores SessionID. After the Internet is easy to find, the name is: ASP.NET_SessionId, this is the Cookies name of SessionId. We can write this in Session_Start:

The copy code is as follows:

Protected void Session_Start (object sender, EventArgs e)

{

Response.Cookies ["ASP.NET_SessionId"] .Value = Session.SessionID.ToString ()

Response.Cookies ["ASP.NET_SessionId"] .Domain = ".jb51.net"

}

The code means that at the beginning of each session, I rewrite the Cookie of ASP.NET_SessionId to our existing SessionID and designate the domain of this Cookie as the parent domain, such as .jb51.net, so that Session sharing across child domains can be implemented. How's it going? it's easy, right?

We also have an external problem, that is, the problem of client-side storage is solved, but what about the server-side Session? In general, our different subdomains point to different servers, such as user.jb51.net dedicated to a single server, yellow.jb51.net dedicated to a single server. At this time, not to mention the process, they are not even physically the same. How to share Session? At this point, another method is used. our default Session is stored in the asp.net process, so we can't access each other, as shown below:

The copy code is as follows:

We can modify it to State Server mode, which 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 Session services, as follows:

The copy code is as follows:

In this way, Session sharing among different subdomains is fully implemented.

Earlier, I mentioned the way Url saves SessionId. Since it is not commonly used, I will show you how to configure it as follows:

The copy code is as follows:

The cookieless attribute specifies whether to use cookie to save the SessionId, and we run it to get something like this:

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

At this point, I believe you have a deeper understanding of "the specific methods of sharing Session in different subdomains in ASP.NET". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

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.