Asp.net supports single-point logon for multiple subdomains

Asp.net supports single-point logon for multiple subdomainsAuthor: sithere Date:

Problem:
The website has bbs.xxx.com/main.xxx.com/pay.xxx.com, which are three different second-level websites. to log on to any second-level domain name, the sites of other second-level domain names must log on.
Solution:
Set the domain attribute of the cookie.
Details:
Set the cookie domain that saves the user login information to the same.
Usercookie. Domain = ".xxx.com"; note that a "." Must be added before the Domain name ".".
This setting is required during login and exit.
A common practice is to use a class specifically responsible for user login to manage these transactions. In this way, you only need to call this class on other login pages.
If you use asp.net 2.0 and forms for verification, there is a simpler way to complete this setting.
Web. config adds support for domains. You only need to follow the settings below: program code <authentication mode = "Forms">
<Forms loginUrl = "Login. aspx" domain = ".xxx.com" name = ". auto‑usitecookie"/>
</Authentication>

Domain: Optional attribute.
Specifies the optional fields set in the outgoing Forms authentication Cookie. This setting takes precedence over the domain used in the httpCookies element.
This attribute is a new attribute in. NET Framework 2.0. The default value is an empty string ("").

Note:
No matter which method, the cookie name must be the same.

A single logon means that when a user logs on to another website, such as www.studyez.com, and switches to communty.studyez.com, the user is automatically identified as logged on by the community Server, after a user logs out of community.studyez.com and switches to www.studyez.com, the www Server determines that the user has logged out.

Restrictions:
1. All sites requiring single-point logon share the same user database. This does not need to be explained.

2. All sites must be under the same parent domain name. Single Sign-On refers to Single Sign-On between different sub-domain names under the same domain name. A direct example is cross-site Single Sign-On between such sites: www.studyez.com, community.studyez.com, serach.studyez.com, mail.studyez.com, mms.studyez.com, etc. They belong to a common parent domain name studyez.com, it is because many sub-systems use different sub-domain names to facilitate development, deployment, and management, and for sites with a large user access volume, each subdomain name may have many servers for servo. This is more in line with the current model and needs of many sites.

For cross-site login between domain names under different parent domain names, the best way is to use the principle of Passport. For specific implementation, refer to the Passport document, so it is not covered in this article.

Principle:

The best way to achieve Single Sign-On between different subdomains is to use Cookie Forms authentication. The principle is to allow cookies generated by Forms Authentication to be accessed across domain names.

First, let's talk about Cookie restrictions. For any Http Request, when it is submitted to the Server, the domain name of the Cookie that it can safely access must be in the path of the HTTP Reuqest domain name. For example, sending a sending request and sending a cookie to the server automatically includes all cookies with the domain name community.corp.studyez.com, .corp.studyez.com, corp.studyez.com, .studyez.com, and studyez.com, this is restricted by the Cookie specification. If the browser does not comply with this specification, there will be a serious security vulnerability, this means that any server can read the cookies left by the same user when accessing other websites.

According to the Cookie restrictions described above, we can conclude that for the previous example of www.studyez.com and community.studyez.com, we are trying to limit the Cookie domain name generated by Forms Authentication to .studyez.com or studyez.com, instead of the default www.studyez.com and communty.studyez.com, this makes it possible to implement a single login requirement.

Write so much today, and write more implementations and limitations in the next few days.

Program code // user Cookie storage key
Public const string CookieUser = "devin_cn_user ";
// User Cookie name key
Public const string CookieUserName = "UserName ";

/// <Summary>
/// Set user Cookie information
/// </Summary>
/// <Param name = "UserName"> User name </param>
/// <Param name = "CookieSave"> Cookie validity period value </param>
Private void SetCookie (string UserName, int CookieSave)
{
// Set the Cookie value
HttpCookie cookie = new HttpCookie (CookieUser );
// Set the Domain Cookie
Cookie. Domain = ".devin.cn ";
// Set the user name
Cookie. Values. Add (CookieUserName, UserName );
// Set the Cookie authentication code
Cookie. Values. Add (CookieUserCode, this. CookieCode (). ToString ());

// Set the Cookie validity period based on the selection.
Switch (CookieSave)
{
Case 0:
Cookie. Expires = DateTime. Now; // Real-Time
Break;
Case 1:
Cookie. Expires = DateTime. Now. AddDays (1); // one day
Break;
Case 2:
Cookie. Expires = DateTime. Now. AddDays (7); // seven days, one week
Break;
Case 3:
Cookie. Expires = DateTime. Now. AddMonths (1); // January
Break;
Case 4:
Cookie. Expires = DateTime. Now. AddYears (1); // a year
Break;
}

// Delete the original Cookie information before saving the Cookie information to avoid duplication
HttpContext. Current. Response. Cookies. Remove (CookieUser );

// Save Cookie Information
HttpContext. Current. Response. SetCookie (cookie );

// Login authentication
FormsAuthentication. RedirectFromLoginPage (UserName, false );
}

That's it.
// Set the Domain Cookie
Cookie. Domain = ".devin.cn ";