Verwandte Wissenspunkte zur domänenübergreifenden Front-End-Zusammenfassung

Dieser Artikel enthält relevante Erklärungen zum Thema Cross-Domain.

Vorwort

Die Vielfalt an domänenübergreifenden Frontend-Lösungen ist wirklich schwindelerregend. Ich bin einmal auf eine solche Interviewszene in einem Unternehmen gestoßen. Sie gingen einer nach dem anderen hinein. Der Interviewer fragte: „Erzählen Sie mir von einer domänenübergreifenden Lösung.“ an die ich mich damals erinnern konnte), und dann sagte der Interviewer: „Jeder von Ihnen hat diese drei gesagt, als Sie hereinkamen. Was gibt es außer diesen noch?“, und plötzlich war es chaotisch im Wind. .. In diesem Fall kann ich nur einen Blog zusammenfassen, um die Lücken zu überprüfen und zu schließen.

1. Was ist domänenübergreifend?

Das Wort Cross-Domain bedeutet wörtlich Cross-Domain, aber tatsächlich ist der Umfang von Cross-Domain definitiv nicht so eng. Das spezifische Konzept lautet wie folgt: Solange Protokoll, Domänenname und Port unterschiedlich sind, werden sie als unterschiedliche Domänen betrachtet. Der Grund, warum domänenübergreifende Probleme auftreten, ist eigentlich leicht zu verstehen. Wenn beiläufig auf externe Dateien verwiesen wird und Seiten unter verschiedenen Tags auf ähnliche Dateien verweisen, wird der Browser leicht verwirrt und die Sicherheit ist nicht gewährleistet. Bei allem steht die Sicherheit an erster Stelle. Zusätzlich zu den Sicherheitseinschränkungen bringt es jedoch auch große Probleme mit sich, Iframe- oder Ajax-Anwendungen einzuschleusen. Daher müssen wir einige Methoden verwenden, um js in dieser Domäne zu ermöglichen, Seitenobjekte in anderen Domänen zu betreiben, oder um js in anderen Domänen zu ermöglichen, Seitenobjekte in dieser Domäne (zwischen Iframes) zu betreiben. Im Folgenden finden Sie eine detaillierte Erläuterung der spezifischen domänenübergreifenden Situation:                                                                                                  Kommunikation zulassen

http://www.a.com/a.jshttp://www.a.com/b.js​ ​ ​ ​ Der gleiche Domänenname Als nächstes erlauben Sie http://www.a.com/lab/a.jshttp://www.a.com/script/b.js Verschiedene Ordner unter demselben Domänennamen erlauben http: //www.a.com:8000/ a.js http://www.a.com/b.js Der gleiche Domänenname, unterschiedliche Ports sind nicht zulässig http://www.a.com/a.js https ://www.a.com/b.js Derselbe Domänenname, unterschiedliche Protokolle sind nicht zulässig. http://www.a.com/a.jshttp://70.32.92.74/b.js Der Domänenname und die entsprechende IP des Domänennamens sind nicht zulässig http://www.a.com/a.jshttp:// script.a.com/b.js Die Hauptdomäne ist dieselbe, aber die Unterdomäne ist unterschiedlich. Der Zugriff auf Cookies ist in diesem Fall nicht zulässig) http://www.a.com/a.jshttp://a.com/b .js Gleicher Domainname, unterschiedliche Second-Level-Domainnamen (wie oben) Nicht zulässig (der Zugriff auf Cookies ist in diesem Fall nicht zulässig) http://www.cnblogs.com/a.jshttp://www.a.com/b.js Unterschiedliche Domainnamen sind nicht zulässig

Zwei Punkte sind zu beachten:

Bei domänenübergreifenden Problemen durch Protokolle und Ports ist die „Rezeption“ machtlos

bei domänenübergreifenden Problemen Das Problem besteht darin, dass die Domäne nur durch den „URL-Header“ identifiziert wird, ohne dass versucht wird, festzustellen, ob dieselbe IP-Adresse zwei Domänen entspricht oder ob sich die beiden Domänen auf derselben IP befinden.

(„URL-Header“ bezieht sich auf window.location.protocol +window.location.host, was auch als „Domänen, Protokolle und Ports müssen übereinstimmen“ verstanden werden kann.)

Same Origin Policy

Derselbe Domänenname (oder die gleiche IP), derselbe Port und das gleiche Protokoll werden als dieselbe Domäne betrachtet. Es versteht sich, dass Skripte in dieser Domäne nur Berechtigungen haben Lese- und Schreibressourcen in dieser Domäne, kann jedoch nicht auf andere Domänenressourcen zugreifen. Diese Sicherheitsbeschränkung wird als Same-Origin-Richtlinie bezeichnet.

Die Same-Origin-Richtlinie ist die grundlegendste Sicherheitsfunktion des Browsers. Ohne eine Same-Origin-Richtlinie hätten normale Benutzer überhaupt keine Sicherheit. Alle privaten Informationen der Benutzer können von jedermann abgerufen werden, beispielsweise Website-Cookies und E-Mail-Inhalte. Es ist auch anfällig für CSRF-Angriffe.

Es ist zu beachten, dass der Domänenname und die entsprechende IP-Adresse des Domänennamens aus unterschiedlichen Quellen stammen. Wenn der Hauptdomänenname derselbe ist, stammen auch die Subdomänennamen aus unterschiedlichen Quellen.

Domänenübergreifende Lösung (Zusammenfassung)

1. document.domain domänenübergreifend

Wie bereits erwähnt, verfügt der Browser über eine Same-Origin-Richtlinie und eine seiner Einschränkungen besteht darin, dass er über die Ajax-Methode keine Dokumente aus verschiedenen Quellen anfordern kann. Die zweite Einschränkung besteht darin, dass js nicht zwischen Frames in verschiedenen Domänen im Browser interagieren kann.
Fensterobjekte können zwischen verschiedenen Frameworks abgerufen werden, die entsprechenden Eigenschaften und Methoden können jedoch nicht abgerufen werden.
Zum Beispiel gibt es eine Seite, deren Adresse http://www.damonare.cn/a.html ist, es gibt einen Iframe auf dieser Seite, dessen Quelle http://damonare.cn/b.html ist , Offensichtlich befinden sich diese Seite und der darin enthaltene Iframe in unterschiedlichen Domänen, sodass wir die Dinge im Iframe nicht erhalten können, indem wir js-Code wie diesen auf der Seite schreiben:

<script type="text/javascript">
    function test(){        var iframe = document.getElementById(&#39;ifame&#39;);

   var win = document.contentWindow; //可以获取到iframe里的window对象，但该window对象的属性和方法几乎是不可用的
        var doc = win.document; //这里获取不到iframe里的document对象
        var name = win.name; //这里同样获取不到window对象的name属性
    }</script><iframe id = "iframe" src="http://damonare.cn/b.html" onload = "test()"></iframe>

Zu diesem Zeitpunkt document.domain Dies wird Das ist praktisch. Wir müssen nur die document.domain der beiden Seiten http://www.damonare.cn/a.html und http://damonare.cn/b.html auf denselben Domainnamen setzen .

Hinweis: Die Einstellung von document.domain ist nur auf sich selbst oder eine übergeordnete Domäne einer höheren Ebene festgelegt, und die Hauptdomäne muss dieselbe sein.

Dokument.domain auf der Seite http://www.damonare.cn/a.html festlegen:

<iframe id = "iframe" src="http://damonare.cn/b.html" onload = "test()"></iframe><script type="text/javascript">
    document.domain = &#39;damonare.cn&#39;;//设置成主域
    function test(){        //contentWindow 可取得子窗口的 window 对象
        alert(document.getElementById(&#39;iframe&#39;).contentWindow);
    }</script>

Auch auf der Seite http://damonare.cn/b.html festlegen document.domain:

Die Methode zum Ändern von document.domain ist nur auf die Interaktion zwischen Frames in verschiedenen Subdomains anwendbar.

2. Domänenübergreifend über location.hash

Weil das übergeordnete Fenster die URL des Iframes lesen und schreiben kann und der Iframe auch die URL des übergeordneten Fensters lesen und schreiben kann. Ein Teil der URL wird als Hash bezeichnet. Das #-Zeichen und die darauf folgenden Zeichen werden im Allgemeinen für die Positionierung des Browser-Ankers verwendet. Der Server kümmert sich nicht um diesen Teil. Es sollte gesagt werden, dass der Hash nicht in der HTTP-Anfrage enthalten ist Daher wird durch die Änderung dieses Teils keine HTTP-Anfrage generiert, sondern ein Browserverlauf generiert. Das Prinzip dieser Methode besteht darin, den Hash-Teil der URL für eine bidirektionale Kommunikation zu ändern. Jedes Fenster sendet Nachrichten, indem es den Speicherort anderer Fenster ändert (da sich die beiden Seiten nicht in derselben Domäne befinden, erlauben IE und Chrome keine Änderung des Werts von parent.location.hash, sodass ein Proxy-Iframe unter dem Domänennamen des Fensters gesendet wird (übergeordnetes Fenster ist erforderlich). Und empfangen Sie Nachrichten, indem Sie auf Änderungen in Ihrer eigenen URL warten. Diese Kommunikationsmethode führt zu einigen unnötigen Browserverlaufsdatensätzen, und einige Browser unterstützen das Onhashchange-Ereignis nicht und müssen abfragen, um URL-Änderungen zu erfahren. Schließlich weist diese Methode auch Nachteile auf, z. B. die direkte Offenlegung von Daten in der URL Kapazität und Typ sind begrenzt usw.

Beispiel:
Angenommen, die übergeordnete Seite ist baidu.com/a.html und die im Iframe eingebettete Seite ist google.com/b.html (der Domainname und andere URL-Attribute werden hier weggelassen). ), um dies zu erreichen. Die Kommunikation zwischen den beiden Seiten kann über die folgenden Methoden erfolgen:

a.html überträgt Daten an b.html

a.html und ändert die Quelle des Iframes in google.com/b.html#paco

b.html erkennt Änderungen in der URL und löst entsprechende Vorgänge aus

b.html überträgt Daten an a.html Da die beiden Seiten nicht vorhanden sind Dieselbe Domäne, IE und Chrome erlauben keine Änderung des übergeordneten .location.hash-Werts, daher müssen wir einen Proxy-Iframe unter dem Domänennamen des übergeordneten Fensters verwenden, um einen versteckten Iframe unter

b.html zu erstellen src dieses Iframes befindet sich unter der Domäne baidu.com und hängt die zu übertragenden Hash-Daten an, z. B. src=“http://www.baidu.com/proxy.html#data“

Proxy .html überwacht die URL-Änderung und ändert die URL von a.html (da sich .html und *proxy.html in derselben Domäne befinden, kann Proxy.html den URL-Hash von a.html ändern)

a.html hört auf Änderungen in der URL und löst entsprechende Vorgänge aus

b.html Der Schlüsselcode der Seite lautet wie folgt:

try {  
    parent.location.hash = 'data';  
} catch (e) {  
    // ie、chrome的安全机制无法修改parent.location.hash，  
    var ifrproxy = document.createElement('iframe');  
    ifrproxy.style.display = 'none';  
    ifrproxy.src = "http://www.baidu.com/proxy.html#data";  
    document.body.appendChild(ifrproxy);  
}

Der Schlüsselcode der Seite „proxy.html“ lautet wie folgt :

/**
*Da parent.parent (d. h. baidu.com/a.html) und baidu.com/proxy.html zur selben Domäne gehören,
kann der Wert seines location.hash geändert werden**/ parent.parent.location.hash = self.location.hash(1);

3. Domänenübergreifend über HTML5 postMessage-Methode

Die erweiterten Browser IE8+, Chrome, Firefox, Opera und Safari unterstützen diese Funktion.
Diese Funktion umfasst hauptsächlich das Ereignis „message“ zum Empfangen von Informationen und die Methode „postMessage“ zum Senden von Nachrichten.
Zum Beispiel bettet Seite A der Domain damonare.cn eine Seite B der Domain google.com über einen Iframe ein. Die Kommunikation zwischen A und B kann durch die folgenden Methoden erreicht werden:

Seite A sendet Nachrichten über die postMessage-Methode:

window.onload = function() {  
    var ifr = document.getElementById('ifr');  
    var targetOrigin = "http://www.google.com";  
    ifr.contentWindow.postMessage('hello world!', targetOrigin);  
};

So verwenden Sie postMessage: otherWindow.postMessage(message, targetOrigin);

otherWindow: bezieht sich auf das Zielfenster, d. h. auf welches Fenster die Nachricht gesendet werden soll Es ist ein Mitglied der window.frames-Eigenschaft oder wird durch das von der .open-Methode erstellte Fenster bestimmt.

Nachricht: ist die zu sendende Nachricht, Typ ist String, Objekt (wird von IE8 und 9 nicht unterstützt).

targetOrigin: dient zur Begrenzung des Nachrichtenempfangsbereichs. Verwenden Sie bitte „*“, wenn es keine Begrenzung gibt.

Seite B hört und akzeptiert Nachrichten über das Nachrichtenereignis:

var onmessage = function (event) {  
  var data = event.data;//消息  
  var origin = event.origin;//消息来源地址  
  var source = event.source;//源Window对象  
  if(origin=="http://www.baidu.com"){  
console.log(data);//hello world!  
  }  
};  
if (typeof window.addEventListener != 'undefined') {  
  window.addEventListener('message', onmessage, false);  
} else if (typeof window.attachEvent != 'undefined') {  
  //for ie  
  window.attachEvent('onmessage', onmessage);  
}

In ähnlicher Weise kann Seite B auch Nachrichten senden, und dann kann Seite A Nachrichten abhören und empfangen.

4. JSONP-domänenübergreifend

以上的这几种都是双向通信的，即两个iframe，页面与iframe，或是页面与页面之间的。
下面说几种单向跨域的（一般用来获取数据），因为通过script标签引入的js是不受同源策略的限制的。
所以我们可以通过script标签引入一个js或者是一个其他后缀形式（如php，jsp等）的文件，此文件返回一个js函数的调用。

比如，有个a.html页面，它里面的代码需要利用ajax获取一个不同域上的json数据，假设这个json数据地址是http://damonare.cn/data.php，那么a.html中的代码就可以这样：

可以看到获取数据的地址后面还有一个callback参数，按惯例是用这个参数名，但是你用其他的也一样。当然如果获取数据的jsonp地址页面不是你自己能控制的，就得按照提供数据的那一方的规定格式来操作了。
因为是当做一个js文件来引入的，所以http://damonare.cn/data.php返回的必须是一个能执行的js文件，所以这个页面的php代码可能是这样的(一定要和后端约定好哦)：

$callback = $_GET['callback'];//得到回调函数名
$data = array('a','b','c');//要返回的数据
echo $callback.'('.json_encode($data).')';//输出?>

最终，输出结果为：dosomething([‘a’,’b’,’c’]);

如果你的页面使用jquery，那么通过它封装的方法就能很方便的来进行jsonp操作了:

<script type="text/javascript">
    $.getJSON(&#39;http://example.com/data.php?callback=?,function(jsondata)&#39;){        //处理获得的json数据
    });</script>

jquery会自动生成一个全局函数来替换callback=?中的问号，之后获取到数据后又会自动销毁，实际上就是起一个临时代理函数的作用。
$.getJSON方法会自动判断是否跨域，不跨域的话，就调用普通的ajax方法；跨域的话，则会以异步加载js文件的形式来调用jsonp的回调函数。

JSONP的优缺点:

JSONP的优点：
它不像XMLHttpRequest对象实现的Ajax请求那样受到同源策略的限制；它的兼容性更好，在更加古老的浏览器中都可以运行，不需要XMLHttpRequest或ActiveX的支持；并且在请求完毕后可以通过调用callback的方式回传结果。

JSONP的缺点：
它只支持GET请求而不支持POST等其它类型的HTTP请求；它只支持跨域HTTP请求这种情况，不能解决不同域的两个页面之间如何进行JavaScript调用的问题。

5. CORS跨域

CORS（Cross-Origin Resource Sharing）跨域资源共享，定义了必须在访问跨域资源时，浏览器与服务器应该如何沟通。
CORS背后的基本思想就是使用自定义的HTTP头部让浏览器与服务器进行沟通，从而决定请求或响应是应该成功还是失败。
目前，所有浏览器都支持该功能，IE浏览器不能低于IE10。整个CORS通信过程，都是浏览器自动完成，不需要用户参与。
对于开发者来说，CORS通信与同源的AJAX通信没有差别，代码完全一样。浏览器一旦发现AJAX请求跨源，就会自动添加一些附加的头信息，有时还会多出一次附加的请求，但用户不会有感觉。

因此，实现CORS通信的关键是服务器。只要服务器实现了CORS接口，就可以跨源通信。

平时的ajax请求可能是这样的:

<script type="text/javascript">
    var xhr = new XMLHttpRequest();
    xhr.open("POST", "/damonare",true);
    xhr.send();</script>

以上damonare部分是相对路径，如果我们要使用CORS，相关Ajax代码可能如下所示：

<script type="text/javascript">
    var xhr = new XMLHttpRequest();
    xhr.open("GET", "http://segmentfault.com/u/andreaxiang/",true);
    xhr.send();</script>

代码与之前的区别就在于相对路径换成了其他域的绝对路径，也就是你要跨域访问的接口地址。

服务器端对于CORS的支持，主要就是通过设置Access-Control-Allow-Origin来进行的。
如果浏览器检测到相应的设置，就可以允许Ajax进行跨域的访问。
关于CORS更多了解可以看下阮一峰老师的这一篇文章：跨域资源共享 CORS 详解

CORS和JSONP对比

JSONP只能实现GET请求，而CORS支持所有类型的HTTP请求。

使用CORS，开发者可以使用普通的XMLHttpRequest发起请求和获得数据，比起JSONP有更好的错误处理。

JSONP主要被老的浏览器支持，它们往往不支持CORS，而绝大多数现代浏览器都已经支持了CORS。

CORS与JSONP相比，无疑更为先进、方便和可靠。

6. 通过window.name跨域

window对象有个name属性，该属性有个特征：即在一个窗口(window)的生命周期内，窗口载入的所有的页面都是共享一个window.name的，每个页面对window.name都有读写的权限，window.name是持久存在一个窗口载入过的所有页面中的，并不会因新页面的载入而进行重置。
比如：我们在任意一个页面输入

window.name = "My window's name";
setTimeout(function(){    window.location.href = "http://damonare.cn/";
},1000)

进入damonare.cn页面后我们再检测再检测 window.name :
window.name; // My window's name

可以看到，如果在一个标签里面跳转网页的话，我们的 window.name 是不会改变的。
基于这个思想，我们可以在某个页面设置好 window.name 的值，然后跳转到另外一个页面。在这个页面中就可以获取到我们刚刚设置的 window.name 了。

由于安全原因，浏览器始终会保持 window.name 是string 类型。

同样这个方法也可以应用到和iframe的交互来，比如：
我的页面(http://damonare.cn/index.html)中内嵌了一个iframe：

在 iframe.html 中设置好了 window.name 为我们要传递的字符串。
我们在 index.html 中写了下面的代码：

var iframe = document.getElementById('iframe');var data = '';
iframe.onload = function() {
    data = iframe.contentWindow.name;
};

报错！肯定的，因为两个页面不同源嘛，想要解决这个问题可以这样干：

var iframe = document.getElementById('iframe');var data = '';
 
iframe.onload = function() {
    iframe.onload = function(){
        data = iframe.contentWindow.name;
    }
    iframe.src = 'about:blank';
};

或者将里面的 about:blank 替换成某个同源页面（about:blank，javascript: 和 data: 中的内容，继承了载入他们的页面的源。）

这种方法与 document.domain 方法相比，放宽了域名后缀要相同的限制，可以从任意页面获取 string 类型的数据。

本篇对跨域做出相应的总结，更多相关知识请关注php中文网。

相关推荐：

前端常见跨域解决方案（全）

什么是跨域？跨域有几种实现形式？

对于函数事件的总结

Das obige ist der detaillierte Inhalt vonVerwandte Wissenspunkte zur domänenübergreifenden Front-End-Zusammenfassung. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!