asp.net regarding cookie cross-domain issues-C#.Net Tutorial-php.cn

asp.net regarding cookie cross-domain issues

伊谢尔伦

Release： 2016-11-25 09:19:28

Original

1704 people have browsed it

Cookies are a great invention that allow web developers to retain their users' logged-in status. But problems arise when your site has more than one domain name. According to the cookie specification, a cookie can only be used for one domain name and cannot be sent to other domain names. Therefore, if a cookie is set in the browser for one domain name, the cookie will not be valid for other domain names. If you want your users to log in from one of your sites and also log in from other domains, this can be a real problem.

Across second-level domain names

We know that cookies can be accessed across second-level domain names. This is easy to understand. For example, if you create a cookie in the web application of www.test1.com, you want to use it in bbs.test1.com To access such an application corresponding to a second-level domain name, you must set the domain parameter domain=test1.com when creating the cookie. Taking asp.net as an example, the code is as follows:

HttpCookie cookie = new HttpCookie("name", "www.Admin10000.com");
cookie.Domain = "test1.com";
cookie.Path = "/";
Response.Cookies.Add(cookie);

Copy after login

Cross top-level domain name

　If I am not a second-level domain name but completely in a different top-level domain name, for example, the web application where www.test1.com is located creates a cookie, and I want What should I do if I access www.test2.com or its second-level domain name application? We know that it cannot be accessed by conventional countermeasures. The key is to see if there is any way to access it. The fact is that cookies can cross domains under certain conditions, rather than achieving cross-domain at will.

Let’s do a test to see how the two sites www.test1.com and www.test2.com implement cookie cross-domain access. According to convention, we need to have 2 top-level domain names and a DNS server to configure the domain name, otherwise we cannot verify it, but we don't need to be so troublesome here. We can simulate it by modifying the hosts file. There is a hosts file in c:windowssystem32driversetc. Add the two lines

127.0.0.1    www.test1.com
127.0.0.1    www.test2.com

Copy after login

at the end, and you can use the above domain name to access the local loopback address. We only need to deploy a set of programs on IIS. The IP is the loopback address of the local machine and can be accessed using two domain names.

　 We create three new pages, namely Default.aspx, SSO.ashx, and GetCookie.aspx.

　 Among them, Default.aspx is the page of www.test1.com, and the accessed address is http://www.test1.com/Default.aspx. Take a look at the front-end code, it does not have any back-end 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">
<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
    <title></title>
</head>
<body>
    <form id="form1" runat="server">
    <div>
              <script type="text/javascript">
            var _frm = document.createElement("iframe");
            _frm.style.display = "none";
            _frm.src = "http://www.test2.com/SSO.ashx";
            document.body.appendChild(_frm);  
        </script>
       </div>
    </form>
</body>
</html>

Copy after login

The other one is the SSO.ashx page, we think it is the page of www.test2.com, the front-end does not have any code, the back-end 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$ 的摘要说明
    /// </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");
            cookie.Domain = "test2.com";
            cookie.Path = "/";
            cookie.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;
            }
        }
    }
}

Copy after login

The last is GetCookie.aspx Page, it is also a page under www.test2.com, there is no front-end code, only back-end 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);
            }
        }
    }
}

Copy after login

Okay, now we access the test by accessing http://www.test1.com/Default.aspx After that, the SSO.ashx page will be loaded through the iframe, the background code will be executed to create the cookie, and then we will visit http://www.test2.com/GetCookie.aspx and we will get the corresponding cookie. Note that cookies created under www.test1.com can be accessed under www.test2.com.

Things to note:

　admin10000.com Tips There is a sentence in the background code of SSO.ashx: context.Response.AddHeader("P3P", "CP=CAO PSA OUR"); is used to set the P3P response header. It is because the P3P supported by IE browser causes cookies to be blocked when iframe cross-site, and cookies cannot be created. (FireFox currently does not support P3P security features, and FireFox naturally does not have this problem. There is no need to add a P3P response header.)

Use the src attribute of the iframe to redirect the cookie value in the test1.com domain as the get parameter to test2. On the SSO.ashx page under the com domain, SSO.ashx obtains the cookie value passed from the test1.com domain and writes the obtained value into the cookie, thus simply realizing cross-domain cookie access.

　 In addition, the Default.aspx page can also be changed to JS calling 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">
<html xmlns="http://www.w3.org/1999/xhtml" >
<head runat="server">
    <title></title>
</head>
<body>
    <form id="form1" runat="server">
    <div>
        <script type="text/javascript" src="http://www.test2.com/SSO.ashx"></script>
    </div>
    </form>
</body>
</html>

Copy after login