Diese Seite wurde von der Cloud Translation API übersetzt.

Anleitung zum Aktivieren der ursprungsübergreifenden Isolierung

Mit der ursprungsübergreifenden Isolierung können auf einer Webseite leistungsstarke Funktionen wie „SharedArrayBuffer“ verwendet werden. In diesem Artikel wird erläutert, wie Sie die plattformübergreifende Isolation auf Ihrer Website aktivieren.

Eiji Kitamura

In dieser Anleitung erfahren Sie, wie Sie die plattformübergreifende Isolation aktivieren. Die plattformübergreifende Isolation ist erforderlich, wenn Sie SharedArrayBuffer, performance.measureUserAgentSpecificMemory() oder einen Timer mit hoher Auflösung und besserer Präzision verwenden möchten.

Wenn Sie die ursprungsübergreifende Isolation aktivieren möchten, sollten Sie die Auswirkungen auf andere ursprungsübergreifende Ressourcen auf Ihrer Website wie Anzeigen-Placements prüfen.

Ermitteln, wo auf Ihrer Website SharedArrayBuffer verwendet wird

Ab Chrome 92 funktionieren Funktionen, die SharedArrayBuffer verwenden, nicht mehr ohne ursprungsübergreifende Isolierung. Wenn Sie aufgrund einer Meldung zur Einstellung von SharedArrayBuffer auf diese Seite gelangt sind, wird SharedArrayBuffer wahrscheinlich entweder auf Ihrer Website oder in einer der eingebetteten Ressourcen verwendet. Damit auf Ihrer Website aufgrund der Einstellung keine Probleme auftreten, sollten Sie zuerst ermitteln, wo die Funktion verwendet wird.

Wenn Sie nicht sicher sind, wo auf Ihrer Website ein SharedArrayBuffer verwendet wird, haben Sie zwei Möglichkeiten, das herauszufinden:

Chrome-Entwicklertools verwenden
(Fortgeschrittene Nutzer) Einstellungsberichte verwenden

Wenn Sie bereits wissen, wo Sie SharedArrayBuffer verwenden, fahren Sie mit Auswirkungen der ursprungsübergreifenden Isolierung analysieren fort.

Chrome-Entwicklertools verwenden

Mit den Chrome-Entwicklertools können Entwickler Websites prüfen.

Öffnen Sie die Chrome-Entwicklertools auf der Seite, auf der Sie vermuten, dass SharedArrayBuffer verwendet wird.
Wählen Sie das Steuerfeld Console aus.

Wenn auf der Seite SharedArrayBuffer verwendet wird, wird die folgende Meldung angezeigt:

[Deprecation] SharedArrayBuffer will require cross-origin isolation as of M92, around May 2021. See https://developer.chrome.com/blog/enabling-shared-array-buffer/ for more details. common-bundle.js:535

Der Dateiname und die Zeilennummer am Ende der Nachricht (z. B. common-bundle.js:535) geben an, woher die SharedArrayBuffer stammt. Wenn es sich um eine Bibliothek eines Drittanbieters handelt, wenden Sie sich an den Entwickler, um das Problem zu beheben. Wenn es als Teil Ihrer Website implementiert ist, folgen Sie der Anleitung unten, um die plattformübergreifende Isolation zu aktivieren.

DevToools Console-Warnung, wenn „SharedArrayBuffer“ ohne ursprungsübergreifende Isolierung verwendet wird — Warnung in der Entwicklertools-Konsole, wenn SharedArrayBuffer ohne ursprungsübergreifende Isolierung verwendet wird.

(Fortgeschrittene Nutzer) Einstellungsberichte verwenden

Einige Browser haben eine Funktion zum Melden der Einstellung von APIs an einen bestimmten Endpunkt.

Richten Sie einen Berichtsserver für die Einstellung ein und rufen Sie die URL für die Berichterstellung ab. Sie können dazu entweder einen öffentlichen Dienst verwenden oder einen selbst erstellen.
Lege mithilfe der URL den folgenden HTTP-Header auf Seiten fest, auf denen möglicherweise SharedArrayBuffer ausgeliefert wird.
```
Report-To: {"group":"default","max_age":86400,"endpoints":[{"url":"THE_DEPRECATION_ENDPOINT_URL"}]}
```
Sobald der Header weitergeleitet wird, sollten über den Endpunkt, für den Sie sich registriert haben, Einstellungsberichte erfasst werden.

Eine Beispielimplementierung finden Sie hier: https://cross-origin-isolation.glitch.me.

Auswirkungen der ursprungsübergreifenden Isolierung analysieren

Wäre es nicht toll, wenn Sie die Auswirkungen der Aktivierung der plattformübergreifenden Isolation auf Ihre Website bewerten könnten, ohne dass etwas kaputtgeht? Mit den HTTP-Headern Cross-Origin-Opener-Policy-Report-Only und Cross-Origin-Embedder-Policy-Report-Only ist das möglich.

Legen Sie Cross-Origin-Opener-Policy-Report-Only: same-origin für das Dokument der obersten Ebene fest. Wie der Name schon sagt, werden mit dieser Überschrift nur Berichte über die Auswirkungen gesendet, die COOP: same-origin auf Ihre Website haben würde. Die Kommunikation mit Pop-up-Fenster wird dadurch nicht deaktiviert.
Richten Sie die Berichterstellung ein und konfigurieren Sie einen Webserver, um die Berichte zu empfangen und zu speichern.
Legen Sie Cross-Origin-Embedder-Policy-Report-Only: require-corp für das Dokument der obersten Ebene fest. Auch hier können Sie mit diesem Header die Auswirkungen der Aktivierung von COEP: require-corp sehen, ohne dass sich dies auf die Funktion Ihrer Website auswirkt. Sie können diesen Header so konfigurieren, dass Berichte an denselben Berichtsserver gesendet werden, den Sie im vorherigen Schritt eingerichtet haben.

Achtung: Wenn Sie die ursprungsübergreifende Isolation aktivieren, wird das Laden von ursprungsübergreifenden Ressourcen blockiert, die Sie nicht explizit aktivieren. Außerdem kann Ihr Dokument auf oberster Ebene nicht mehr mit Pop-up-Fenstern kommunizieren. Wir prüfen derzeit Möglichkeiten, Cross-Origin-Resource-Policy im großen Maßstab bereitzustellen, da für die ursprungsübergreifende Isolierung alle Unterressourcen explizit aktiviert werden müssen. Wir haben uns daher entschlossen, in die entgegengesetzte Richtung zu gehen: Ein neuer „ohne Anmeldedaten“-Modus für COEP, der das Laden von Ressourcen ohne CORP-Header ermöglicht, indem alle Anmeldedaten entfernt werden. Wir hoffen, dass Sie so leichter dafür sorgen können, dass die untergeordneten Ressourcen den Cross-Origin-Resource-Policy-Header senden. Der credentialless-Modus ist zwar in Chrome ab Version 96 verfügbar, wird aber noch von keinem anderen Browser unterstützt. Das kann dazu führen, dass es für einige Entwickler in dieser Phase schwierig ist, COOP oder COEP zu implementieren. Es ist auch bekannt, dass der Cross-Origin-Opener-Policy: same-origin-Header Integrationen beeinträchtigt, die ursprungsübergreifende Fensterinteraktionen wie OAuth und Zahlungen erfordern. Um dieses Problem zu beheben, prüfen wir, ob wir die Bedingung lockern können, um die ursprungsübergreifende Isolierung für Cross-Origin-Opener-Policy: same-origin-allow-popups zu aktivieren. Auf diese Weise ist die Kommunikation nur mit dem geöffneten Fenster möglich. Wenn Sie die ursprungsübergreifende Isolierung aktivieren möchten, aber von diesen Herausforderungen blockiert werden, empfehlen wir Ihnen, sich für einen Ursprungstest zu registrieren und zu warten, bis die neuen Modi verfügbar sind. Wir planen nicht, den Test für die ursprüngliche Version vor der Einführung dieser neuen Modi zu beenden.

Auswirkungen der ursprungsübergreifenden Isolierung minimieren

Nachdem Sie ermittelt haben, welche Ressourcen von der plattformübergreifenden Isolation betroffen sind, finden Sie hier allgemeine Richtlinien dazu, wie Sie diese plattformübergreifenden Ressourcen aktivieren:

Legen Sie für ursprungsübergreifende Ressourcen wie Bilder, Skripts, Stylesheets, iFrames und andere den Cross-Origin-Resource-Policy: cross-origin-Header fest. Legen Sie für Ressourcen auf derselben Website den Header Cross-Origin-Resource-Policy: same-site fest.
Für Ressourcen, die mit CORS geladen werden können, muss der Dienst aktiviert sein. Legen Sie dazu das Attribut crossorigin im entsprechenden HTML-Tag fest (z. B. <img src="example.jpg" crossorigin>). Achten Sie bei JavaScript-Abrufanfragen darauf, dass request.mode auf cors gesetzt ist.
Wenn Sie leistungsstarke Funktionen wie SharedArrayBuffer in einem geladenen iframe verwenden möchten, hängen Sie allow="cross-origin-isolated" an <iframe> an.
Wenn ursprungsübergreifende Ressourcen, die in iFrames oder Worker-Skripts geladen werden, eine andere Ebene von iFrames oder Worker-Skripts umfassen, wenden Sie die in diesem Abschnitt beschriebenen Schritte rekursiv an, bevor Sie fortfahren.
Sobald Sie bestätigt haben, dass alle plattformübergreifenden Ressourcen aktiviert sind, legen Sie den Cross-Origin-Embedder-Policy: require-corp-Header für iframes und Worker-Scripts fest. Dies ist unabhängig von der Herkunft der Ressourcen erforderlich.
Es dürfen keine Pop-up-Fenster mit unterschiedlichen Ursprüngen vorhanden sein, für die die Kommunikation über postMessage() erforderlich ist. Wenn die plattformübergreifende Isolation aktiviert ist, können sie nicht mehr verwendet werden. Sie können die Kommunikation in ein anderes Dokument verschieben, das nicht ursprungsübergreifend isoliert ist, oder eine andere Kommunikationsmethode verwenden (z. B. HTTP-Anfragen).

Cross-Origin-Isolation aktivieren

Nachdem Sie die Auswirkungen durch die ursprungsübergreifende Isolation minimiert haben, finden Sie hier allgemeine Richtlinien zum Aktivieren der ursprungsübergreifenden Isolation:

Legen Sie den Header Cross-Origin-Opener-Policy: same-origin für das Dokument auf oberster Ebene fest. Wenn Sie Cross-Origin-Opener-Policy-Report-Only: same-origin festgelegt haben, ersetzen Sie ihn. Dadurch wird die Kommunikation zwischen dem übergeordneten Dokument und seinen Pop-up-Fenster blockiert.
Legen Sie die Cross-Origin-Embedder-Policy: require-corp-Überschrift im Dokument der obersten Ebene fest. Wenn Sie Cross-Origin-Embedder-Policy-Report-Only: require-corp festgelegt haben, ersetzen Sie es. Dadurch wird das Laden von ursprungsübergreifenden Ressourcen blockiert, die nicht aktiviert sind.
Prüfen Sie, ob self.crossOriginIsolated in der Console true zurückgibt. So können Sie prüfen, ob Ihre Seite ursprungsübergreifend isoliert ist.

Die plattformübergreifende Isolation auf einem lokalen Server zu aktivieren, kann schwierig sein, da einfache Server das Senden von Headern nicht unterstützen. Sie können Chrome mit dem Befehlszeilen-Flag --enable-features=SharedArrayBuffer starten, um SharedArrayBuffer zu aktivieren, ohne die plattformübergreifende Isolierung zu aktivieren. Hier erfahren Sie, wie Sie Chrome mit einem Befehlszeilen-Flag auf den jeweiligen Plattformen ausführen.