Heim > Artikel > Backend-Entwicklung > asp.net bezüglich domänenübergreifender Cookie-Probleme
asp.net bezüglich domänenübergreifender Cookie-Probleme
- 伊谢尔伦Original
- 2016-11-25 09:19:281696Durchsuche
Cookies sind eine großartige Erfindung, die es Webentwicklern ermöglicht, den Anmeldestatus ihrer Benutzer beizubehalten. Es treten jedoch Probleme auf, wenn Ihre Website über mehr als einen Domainnamen verfügt. Gemäß der Cookie-Spezifikation kann ein Cookie nur für einen Domainnamen verwendet werden und nicht an andere Domainnamen gesendet werden. Wenn im Browser ein Cookie für einen Domänennamen gesetzt wird, ist das Cookie daher für andere Domänennamen nicht gültig. Wenn Sie möchten, dass sich Ihre Benutzer von einer Ihrer Websites aus und auch von anderen Domänen aus anmelden, kann dies ein echtes Problem sein.
Über Domänennamen der zweiten Ebene hinweg
Wir wissen, dass auf Cookies über Domänennamen der zweiten Ebene zugegriffen werden kann. Dies ist beispielsweise leicht zu verstehen, wenn Ihre Webanwendung unter www.test1. com erstellt ein Cookie. Wenn Sie auf die Anwendung zugreifen möchten, die einem Domänennamen der zweiten Ebene wie bbs.test1.com entspricht, müssen Sie beim Erstellen des Cookies den Domänenparameter domain=test1.com festlegen. Am Beispiel von asp.net lautet der Code wie folgt:
HttpCookie cookie = new HttpCookie("name", "www.Admin10000.com");
cookie.Domain = "test1.com";
cookie.Path = "/";
Response.Cookies.Add(cookie);Cross-Top-Level-Domain-Name
Wenn ich keinen Second-Level-Domain-Namen, sondern einen anderen Top-Level habe -Domänenname, zum Beispiel, wo sich www.test1.com befindet. Die Webanwendung erstellt ein Cookie und möchte darauf in der Anwendung von www.test2.com oder dem Domänennamen der zweiten Ebene zugreifen. Was soll ich tun? Wir wissen, dass mit herkömmlichen Gegenmaßnahmen nicht darauf zugegriffen werden kann. Der Schlüssel liegt darin, herauszufinden, ob es eine Möglichkeit gibt, darauf zuzugreifen. Tatsache ist, dass Cookies unter bestimmten Bedingungen domänenübergreifend sein können, anstatt nach Belieben domänenübergreifend zu sein.
Machen wir einen Test, um zu sehen, wie die beiden Websites www.test1.com und www.test2.com den domänenübergreifenden Cookie-Zugriff implementieren. Gemäß der Konvention benötigen wir zwei Domänennamen der obersten Ebene und einen DNS-Server, um den Domänennamen zu konfigurieren. Andernfalls können wir ihn nicht überprüfen, aber wir müssen hier nicht so mühsam sein. Wir können ihn durch Ändern der Hosts simulieren Datei. Es gibt eine Hosts-Datei in c:windowssystem32driversetc. Fügen Sie am Ende die Zeilen
127.0.0.1 www.test1.com 127.0.0.1 www.test2.com
hinzu, und Sie können den oben genannten Domänennamen verwenden, um auf die lokale Loopback-Adresse zuzugreifen. Wir müssen lediglich eine Reihe von Programmen auf IIS bereitstellen. Die IP ist die Loopback-Adresse des lokalen Computers und kann über zwei Domänennamen aufgerufen werden.
Wir erstellen drei neue Seiten, nämlich Default.aspx, SSO.ashx und GetCookie.aspx.
Wobei Default.aspx die Seite von www.test1.com ist und die aufgerufene Adresse http://www.test1.com/Default.aspx ist. Schauen Sie sich den Front-End-Code an, er hat keinen 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>Die andere ist die SSO.ashx-Seite, wir denken, es ist die Seite von www.test2.com , das Front-End hat keinen Code, der Back-End-Code lautet wie folgt:
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;
}
}
}
}Die letzte ist die Seite GetCookie.aspx, die auch eine Seite unter www.test2 ist .com. Es gibt keinen Front-End-Code, nur 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);
}
}
}
}OK Jetzt greifen wir auf den Test zu. aspx, die Seite SSO.ashx wird über iframe geladen, der Hintergrundcode wird ausgeführt, um ein Cookie zu erstellen, und dann http:// www.test2.com/GetCookie.aspx Wir haben das entsprechende Cookie erhalten. Beachten Sie, dass unter www.test1.com erstellte Cookies unter www.test2.com abgerufen werden können.
Zu beachtende Dinge:
admin10000.com meldet, dass im Hintergrundcode von SSO.ashx ein Satz vorhanden ist: context.Response.AddHeader("P3P", "CP=CAO PSA OUR "); Wird verwendet, um den P3P-Antwortheader festzulegen. Dies liegt daran, dass das vom IE-Browser unterstützte P3P dazu führt, dass Cookies blockiert werden, wenn iframe standortübergreifend ist und keine Cookies erstellt werden können. (FireFox unterstützt derzeit keine P3P-Sicherheitsfunktionen und FireFox hat dieses Problem natürlich nicht. Es ist nicht erforderlich, einen P3P-Antwortheader hinzuzufügen.)
Verwenden Sie das src-Attribut des Iframes, um den Cookie-Wert zurückzusetzen Die test1.com-Domäne wird als Get-Parameter an die SSO.ashx-Seite unter der test2.com-Domäne weitergeleitet. SSO.ashx erhält den von der test1.com-Domäne übergebenen Cookie-Wert und schreibt den erhaltenen Wert in das Cookie der domänenübergreifende Cookie-Zugriff.
Darüber hinaus kann die Seite Default.aspx auch in das JS-Aufrufformular geändert werden:
<%@ 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>