Diese Seite wurde von der Cloud Translation API übersetzt.

Anleitung zum Aktivieren der ursprungsübergreifenden Isolierung

Mit der ursprungsübergreifenden Isolierung kann eine Webseite leistungsstarke Funktionen wie „SharedArrayBuffer“ nutzen. In diesem Artikel wird erläutert, wie du die ursprungsübergreifende Isolierung auf deiner Website aktivierst.

Eiji Kitamura

In diesem Leitfaden erfahren Sie, wie Sie die ursprungsübergreifende Isolierung aktivieren. Die ursprungsübergreifende Isolierung ist erforderlich, wenn Sie SharedArrayBuffer, performance.measureUserAgentSpecificMemory() oder einen hochauflösenden Timer mit höherer Genauigkeit verwenden möchten.

Wenn du die ursprungsübergreifende Isolierung aktivieren möchtest, solltest du die Auswirkungen auf andere ursprungsübergreifende Ressourcen auf deiner Website bewerten, z. B. Anzeigen-Placements.

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 Nachricht zur Einstellung von SharedArrayBuffer auf diese Seite gelangt sind, liegt es wahrscheinlich daran, dass entweder Ihre Website oder eine der darin eingebetteten Ressourcen SharedArrayBuffer verwendet. Um sicherzustellen, dass Ihre Website nicht mehr funktioniert, sollten Sie zuerst herausfinden, wo sie verwendet wird.

Wenn du nicht sicher bist, wo auf deiner Website ein SharedArrayBuffer verwendet wird, gibt es zwei Möglichkeiten, dies herauszufinden:

Chrome-Entwicklertools verwenden
(Fortgeschritten) 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, von der Sie vermuten, dass sie SharedArrayBuffer verwenden.
Wählen Sie das Steuerfeld Console aus.

Wenn die Seite SharedArrayBuffer verwendet, 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 deiner Website implementiert wird, folge der Anleitung unten, um die ursprungsübergreifende Isolierung zu aktivieren.

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

(Fortgeschritten) Einstellungsberichte verwenden

Einige Browser haben eine Funktion, durch die APIs für einen bestimmten Endpunkt eingestellt werden.

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

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

Auswirkungen der ursprungsübergreifenden Isolierung analysieren

Wäre es nicht großartig, wenn Sie die Auswirkungen der Aktivierung der ursprungsübergreifenden Isolierung auf Ihre Website bewerten könnten, ohne dass dabei tatsächlich Probleme auftreten? Mit den HTTP-Headern Cross-Origin-Opener-Policy-Report-Only und Cross-Origin-Embedder-Policy-Report-Only ist genau das möglich.

Legen Sie Cross-Origin-Opener-Policy-Report-Only: same-origin im Dokument auf oberster Ebene fest. Wie der Name schon sagt, sendet dieser Header nur Berichte über die Auswirkungen, die COOP: same-origin auf Ihre Website haben würde. Die Kommunikation mit Pop-up-Fenstern 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 im Dokument auf oberster Ebene fest. Auch hier zeigt dieser Header die Auswirkungen der Aktivierung von COEP: require-corp, ohne dass die Funktion Ihrer Website tatsächlich beeinträchtigt wird. Sie können diesen Header so konfigurieren, dass Berichte an denselben Berichterstellungsserver gesendet werden, den Sie im vorherigen Schritt eingerichtet haben.

Achtung : Wenn Sie die ursprungsübergreifende Isolierung aktivieren, wird das Laden von ursprungsübergreifenden Ressourcen, die Sie nicht explizit aktiviert haben, blockiert. Außerdem kann das Dokument auf oberster Ebene nicht über Pop-up-Fenster kommunizieren. Wir haben nach Möglichkeiten gesucht, Cross-Origin-Resource-Policy in großem Umfang bereitzustellen, da die ursprungsübergreifende Isolierung erfordert, dass alle Unterressourcen explizit aktiviert werden. Und wir haben die Idee, in die entgegengesetzte Richtung zu gehen: einen neuen COEP-Modus ohne Anmeldedaten, der das Laden von Ressourcen ohne CORP-Header ermöglicht, indem alle Anmeldedaten entfernt werden. Sie müssen dann nicht mehr darauf achten, dass der Cross-Origin-Resource-Policy-Header von den Unterressourcen gesendet wird. Obwohl der credentialless-Modus in Chrome ab Version 96 verfügbar ist, wird er noch von keinem anderen Browser unterstützt. Für einige Entwickler kann dies jedoch zu Problemen bei der Bereitstellung von COOP oder COEP führen. Außerdem ist bekannt, dass der Cross-Origin-Opener-Policy: same-origin-Header Integrationen beeinträchtigt, die ursprungsübergreifende Interaktionen im Fenster erfordern, z. B. OAuth und Zahlungen. Um dieses Problem zu beheben, prüfen wir, wie wir die Bedingung lockern, um die ursprungsübergreifende Isolierung für Cross-Origin-Opener-Policy: same-origin-allow-popups zu aktivieren. Auf diese Weise ist die Kommunikation mit dem geöffneten Fenster möglich. Wenn Sie die ursprungsübergreifende Isolierung aktivieren möchten, aber durch diese Identitätsbestätigungen blockiert sind, empfehlen wir, sich für einen Ursprungstest zu registrieren und zu warten, bis die neuen Modi verfügbar sind. Wir planen nicht, den Ursprungstest zu beenden, bis diese neuen Modi verfügbar sind.

Auswirkungen der ursprungsübergreifenden Isolierung minimieren

Nachdem Sie festgestellt haben, welche Ressourcen von der ursprungsübergreifenden Isolierung betroffen sind, finden Sie hier allgemeine Richtlinien dazu, wie Sie diese ursprungsübergreifenden Ressourcen aktivieren:

Legen Sie für ursprungsübergreifende Ressourcen wie Bilder, Skripts, Stylesheets, iFrames usw. den Cross-Origin-Resource-Policy: cross-origin-Header fest. Legen Sie bei Ressourcen auf derselben Website den Cross-Origin-Resource-Policy: same-site-Header fest.
Bei Ressourcen, die über CORS geladen werden können, muss die Funktion aktiviert sein. Dazu legen Sie das Attribut crossorigin im entsprechenden HTML-Tag fest (z. B. <img src="example.jpg" crossorigin>). Für eine JavaScript-Abrufanfrage muss request.mode auf cors gesetzt sein.
Wenn Sie leistungsstarke Funktionen wie SharedArrayBuffer in einem geladenen iFrame nutzen 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 enthalten, wenden Sie die in diesem Abschnitt beschriebenen Schritte rekursiv an, bevor Sie fortfahren.
Nachdem Sie bestätigt haben, dass alle ursprungsübergreifenden Ressourcen aktiviert sind, legen Sie den Cross-Origin-Embedder-Policy: require-corp-Header in iFrames und Worker-Skripts fest. Dies ist unabhängig von gleicher oder ursprungsübergreifendem Ursprung erforderlich.
Achten Sie darauf, dass keine ursprungsübergreifenden Pop-up-Fenster vorhanden sind, die eine Kommunikation über postMessage() erfordern. Es gibt keine Möglichkeit, sie aufrechtzuerhalten, wenn die ursprungsübergreifende Isolierung aktiviert ist. 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).

Ursprungsübergreifende Isolierung aktivieren

Nachdem Sie die Auswirkungen durch die ursprungsübergreifende Isolierung abgeschwächt haben, finden Sie hier allgemeine Richtlinien für die Aktivierung der ursprungsübergreifenden Isolierung:

Legen Sie den Cross-Origin-Opener-Policy: same-origin-Header im Dokument auf oberster Ebene fest. Wenn du Cross-Origin-Opener-Policy-Report-Only: same-origin festgelegt hast, ersetze diesen. Dadurch wird die Kommunikation zwischen Ihrem Dokument auf oberster Ebene und den zugehörigen Pop-up-Fenstern blockiert.
Legen Sie den Cross-Origin-Embedder-Policy: require-corp-Header im Dokument auf oberster Ebene fest. Wenn du Cross-Origin-Embedder-Policy-Report-Only: require-corp festgelegt hast, ersetze diesen. Dadurch wird das Laden von ursprungsübergreifenden Ressourcen blockiert, die nicht aktiviert sind.
Prüfe, ob self.crossOriginIsolated in der Console true zurückgibt. So kannst du prüfen, ob deine Seite ursprungsübergreifend isoliert ist.

Das Aktivieren der ursprungsübergreifenden Isolierung auf einem lokalen Server kann mühsam sein, da einfache Server das Senden von Headern nicht unterstützen. Du kannst Chrome mit dem Befehlszeilen-Flag --enable-features=SharedArrayBuffer starten, um SharedArrayBuffer zu aktivieren, ohne die ursprungsübergreifende Isolierung zu aktivieren. Hier erfahren Sie, wie Sie Chrome mit einem Befehlszeilen-Flag auf den jeweiligen Plattformen ausführen.