ASP. NET on cookie cross-domain issues

Cookies are a great invention that allows web developers to retain their users ' login status. But when your site has more than one domain name, there will be problems. In the cookie specification, a cookie can only be used for a domain name and cannot be issued to another domain name. Therefore, if you set a cookie in the browser for a domain name, this cookie will not work for the other domain names. If you want your users to log in from one of your sites and also log on to other domains, this is a big challenge.

Cross level two domain name

We know that cookies can be accessed across a two-level domain name, which is a good understanding, such as a cookie created by your www.test1.com Web application. You must set the domain parameter domain=test1.com when creating a cookie if you want to access it in an application with a level two domain name such as bbs.test1.com. Take the ASP. NET example code as follows:

HttpCookie cookie = new HttpCookie ("name", "www.Admin10000.com"), Cookie. Domain = "test1.com"; cookies. Path = "/"; RESPONSE.COOKIES.ADD (cookie);

Cross-top domain

What if I'm not a two-level domain name but completely in a different top-level domain, such as a Web application where www.test1.com creates a cookie that you want to access in www.test2.com or its two-level domain name application? We know that relying on conventional anti-methods is not accessible, the key we are to see if there is no way to access. The fact is that a cookie can be cross-domain under certain conditions, rather than being implemented across domains as it pleases.

Let's take a test to see how the two sites www.test1.com and www.test2.com implement cookie cross-domain access. According to the general we need to have 2 top-level domain names, and there is a DNS server to configure the domain name, otherwise we can not verify, but here we do not need to be so troublesome, we can modify the hosts file to simulate. In C:\windows\system32\drivers\etc, there is a hosts file that adds at the end

127.0.0.1    www.test1.com127.0.0.1    www.test2.com

Two lines, you can use the domain name above to access the native loopback address. We only need to deploy a set of programs on IIS, IP is a native loopback address, with two domain names to access each.

We created three new pages, namely Default.aspx, Sso.ashx, getcookie.aspx.

Where Default.aspx is the www.test1.com page, the address of the visit is http://www.test1.com/Default.aspx. Look at the foreground code, it doesn't have any background code

<%@ page language= "C #" autoeventwireup= "true" codebehind= "Default.aspx.cs" inherits= "Admin10000.Web.Default"% ><! DOCTYPE HTML PUBLIC "-//W3C//DTD XHTML 1.0 transitional//en" "Http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd ">
 Another is the Sso.ashx page, we think it is www.test2.com page, the front desk does not have any code, the background code is as follows: 
 

Using system;using system.collections.generic;using system.linq;using system.web;using System.Web.Services;using System.Web.SessionState; namespace admin10000.web{//<summary>///$codebehindclassname $ for a summary description///</summary> [WebService    (Namespace = "http://tempuri.org/")] [WebServiceBinding (ConformsTo = wsiprofiles.basicprofile1_1)] public class Sso:ihttphandler {public void ProcessRequest (HttpContext context) {HttpCookie cookie = new HttpCookie ("name", "www.            Admin10000.com "); Cookies.            Domain = "test2.com"; Cookies.            Path = "/"; Cookies.            Expires = DateTime.Now.AddMinutes (10000); Context.             RESPONSE.COOKIES.ADD (cookie); Context.            Response.ContentType = "Text/plain"; Context.            Response.AddHeader ("P3P", "Cp=cao PSA our"); Context.        Response.Write ("");            } public bool IsReusable {get {return false;}        }    }} 
Finally is the Getcookie.aspx page, it is also www.test2.com under the page, no foreground code, only the background code:

Using system;using system.collections.generic;using system.linq;using system.web;using System.Web.UI;using System.Web.UI.WebControls; namespace admin10000.web{public    partial class GetCookie:System.Web.UI.Page    {        protected void Page_Load ( Object sender, EventArgs e)        {            if (request.cookies["name"]! = null)            {                Response.Write (request.cookies[ "Name"]. Value);}}}    
Well, now that we have access to the test, by accessing http://www.test1.com/Default.aspx, this page will be loaded through the IFRAME to invoke Sso.ashx, execute the background code to create the cookie, and then access http:// Www.test2.com/GetCookie.aspx we have the corresponding cookie. Note that cookies created under www.test1.com are accessible under www.test2.com.

Places to be aware of:

admin10000.com hint sso.ashx in the background code, there is a sentence: context. Response.AddHeader ("P3P", "Cp=cao PSA our"); is used to set the P3P response header. Cookies are prevented from being created because the P3P supported by IE browser causes the IFRAME to be blocked when it crosses the site. (Firefox does not currently support P3P security features, and Firefox naturally does not have this problem.) You do not need to add a P3P response header. ）

Using the SRC attribute of the IFRAME to redirect the cookie value under the test1.com domain as a get parameter to the SSO.ASHX page in the test2.com domain, Sso.ashx gets the cookie value passed in the Test1.com domain and writes the obtained value to the cookie, so The simple implementation of the cookie cross-domain access.

In addition Default.aspx page can also be changed to JS call form:

<%@ page language= "C #" autoeventwireup= "true" codebehind= "Default.aspx.cs" inherits= "Admin10000.Web.Default"% ><! DOCTYPE HTML PUBLIC "-//W3C//DTD XHTML 1.0 transitional//en" "Http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd ">
