Arbeiten mit der domänenübergreifenden Bibliothek in verschiedenen Internet Explorer-Sicherheitszonen in Add-Ins für SharePoint

Artikel
04/08/2023

Wenn Sie die domänenübergreifende SharePoint-Bibliothek für Ihre Add-Ins verwenden, sollten Sie wissen, wie Sicherheitszonen in Internet Explorer funktionieren. In dem Add-In können Kommunikationsprobleme auftreten, wenn sich die SharePoint-Website und das Add-In in verschiedenen Zonen befinden. In diesem Artikel wird erklärt, was geschieht, wenn Sie die domänenübergreifende Bibliothek in verschiedenen Internet Explorer-Sicherheitszonen verwenden.

Zonenübergreifende Szenarios in Internet Explorer bei Verwendung der domänenübergreifenden SharePoint-Bibliothek

Aus Sicherheitsgründen verhindert Internet Explorer, dass Seiten auf unterschiedlichen Integritätsebenen (auch bekannt als Sicherheitszonen) Cookies freigeben können, da jede Integritätsebene über einen eigenen Cookiespeicher verfügt. Die Integritätsebene einer Seite wird durch die oberste Seite bestimmt, und alle Rahmen innerhalb dieser Seite besitzen die gleiche Integritätsebene. Weitere Informationen finden Sie unter Vorsicht vor der Verwendung der Cookiefreigabe in bereichsübergreifenden Szenarien.

Die domänenübergreifende SharePoint-Bibliothek verwendet ein ausgeblendetes iFrame und eine clientseitige, auf SharePoint gehostete Proxyseite, um die clientseitige Kommunikation mithilfe von JavaScript zu aktivieren. Die domänenübergreifende Bibliothek ist verfügbar, wenn Sie auf Ihren Seiten auf die Datei sp.requestexecutor.js verweisen. Weitere Informationen finden Sie unter Zugreifen auf SharePoint-Daten über Add-Ins mithilfe der domänenübergreifenden Bibliothek.

Wenn sich die Remote-Add-In-Seite und die SharePoint-Website in unterschiedlichen Sicherheitszonen befinden, können keine Autorisierungscookies gesendet werden. Wenn keine Autorisierungscookies vorhanden sind und das iFrame versucht, die Proxyseite zu laden, wird es an die SharePoint-Anmeldeseite weitergeleitet. Die SharePoint-Anmeldeseite kann aus Sicherheitsgründen nicht in einem iFrame enthalten sein. In den folgenden Szenarien kann die Bibliothek die Proxyseite nicht laden, und die Kommunikation mit SharePoint ist nicht möglich.

Das folgende Diagramm zeigt ein bereichsübergreifendes Szenario, in dem die Proxyseite nicht geladen werden kann. Die oberste Seite legt den Rahmen in die gleiche Sicherheitszone wie http://remoteserver/remotepage.html. Die Proxyseite wird nicht geladen.

Zonenübergreifendes Szenario, in dem die Proxyseite nicht geladen werden kann

Zonenübergreifendes Szenario, Proxyseite kann nicht geladen werden

Es folgen einige Beispiele, in denen die domänenübergreifende Bibliothek die Proxyseite unter Umständen nicht laden kann:

Ihre Kunden verwenden SharePoint Online, und Ihre Remote-Add-In-Seite wird auf einem Intranetserver gehostet. Bei diesem Szenario kann der Proxyseite-Ladefehler auftreten, da sich die SharePoint Online-URL in der Regel nicht in der Zone für lokales Intranet befindet. Dies ist ein sehr gängiges Szenario während der anfänglichen Entwicklung eines Add-Ins, da Sie möglicherweise IIS Express oder einen anderen lokalen Server verwenden, um Ihre Seite ohne eine vollqualifizierte Internetdomäne zu hosten.
Ihre Kunden verwenden SharePoint lokal mit formularbasierter Authentifizierung, und die Remoteseite wird von einem Clouddienst gehostet (beispielsweise Microsoft Azure).

Behandeln von zonenübergreifenden Szenarios in SharePoint-Add-Ins

Es gibt einige Möglichkeiten, um dieses Problem zu beheben, sowohl während der Add-In-Entwicklung (dringend empfohlen) als auch zur Add-In-Laufzeit.

Bewährte Methode: Verwenden des apphost-Musters

Für ein bereichsübergreifendes Szenario sollten Sie über eine apphost-Seite in SharePoint verfügen. Die apphost-Seite ist eine SharePoint-Seite, die die Remote-Seite in einem iFrame enthält. Alles innerhalb des iFrame auf der apphost-Seite ist in der gleichen Sicherheitszone wie das Add-In-Web vorhanden. Die domänenübergreifende Bibliothek auf der Remote-Seite kann die Autorisierungs-Cookies erhalten und die Proxyseite erfolgreich laden.

Das folgende Diagramm zeigt ein zonenübergreifendes Szenario, das mithilfe des apphost-Seitenmusters behandelt wird.

Behandlung eines zonenübergreifenden Szenarios mittels apphost-Seitenmuster

Behandlung eines zonenübergreifenden Szenarios mittels apphost

Der für die apphost-Seite erforderliche Code ist einfach. Der Hauptteil der apphost-Seite ist ein SPAppIFrame-Element. Sie müssen CSS verwenden, um den IFrame unsichtbar zu machen, damit es ihr Add-In nicht beeinträchtigt.

Das folgende Markup ist ein Beispiel für eine einfache apphost-Seite. Damit werden die folgenden Aufgaben ausgeführt:

Es deklariert Anweisungen, die beim Verwenden von SharePoint-Komponenten erforderlich sind.
Deklarieren von Formatierungen, um den IFrame unsichtbar zu machen.
Deklarieren des SPAppIFrame-Elements und Festlegen des Ziels auf die Add-In-Startseite.

<%@ Page 
    Inherits="Microsoft.SharePoint.WebPartPages.WebPartPage, Microsoft.SharePoint, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" 
    language="C#" %>
<%@ Register 
    Tagprefix="SharePoint" 
    Namespace="Microsoft.SharePoint.WebControls" 
    Assembly="Microsoft.SharePoint, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
<%@ Register 
    Tagprefix="Utilities" 
    Namespace="Microsoft.SharePoint.Utilities" 
    Assembly="Microsoft.SharePoint, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
<%@ Register 
    Tagprefix="WebPartPages" 
    Namespace="Microsoft.SharePoint.WebPartPages" 
    Assembly="Microsoft.SharePoint, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>

<html>
<head>
    <title>Your add-in page title</title>
    <style type="text/css">
        html, body
        {
            overflow:hidden;
        }
        
        body
        {
            margin:0px;
            padding:0px;
        }
         
        iframe 
        {
            border:0px;
            height:100%;
            width:100%;
        }
    </style>
</head>

<body>
    <SharePoint:SPAppIFrame 
        runat="server" 
        src="~remoteAppUrl/StartPage.html?{StandardTokens}" 
        frameborder="0">
    </SharePoint:SPAppIFrame>
</body>
</html>

Wenn Benutzer über Deep-Links auf Teile des Add-Ins zugreifen können sollen, kann die apphost-Seite mit Inhalten des IFrame zusammenarbeiten, um dies zu ermöglichen. Eine Alternative besteht darin, die postMessage-Methode des IFrame und jeweils verschiedene URLs für jede Seite des Remote-Add-Ins zu verwenden. Um verschiedene URLs für Seiten anzugeben, können Sie einzelne Seiten im Add-In-Web erstellen oder Abfragezeichenfolgen-Parameter für eine Seite verwenden.

Alternatives Muster: Hinzufügen der Websites zu selben Sicherheitszone in Internet Explorer

Selbst wenn ein Add-In nicht unter Verwendung des Apphost-Musters entworfen wurde, können Sie für ihr Funktionieren sorgen, indem Sie die folgenden Domänen derselben Sicherheitszone hinzufügen:

Die Domäne der SharePoint-Website (z. B. https://contoso.sharepoint.com).
Die Domäne des in der Cloud gehosteten Add-Ins (http://remoteserver).
Die Domäne von von Microsoft gehosteten Anmeldeseiten und -diensten (*.microsoftonline.com).

Administratoren können Active Directory-Richtlinien verwenden, um Änderungen an alle Computer in der Organisation zu pushen.

Sicherheitsaspekte bei der Verwendung des apphost-Musters

Es ist wichtig, darauf hinzuweisen, dass das apphost-Muster die Remote-Seite in der gleichen Sicherheitszone wie das Web-Add-In platziert. Stellen Sie sicher, dass Sie die Auswirkungen des Hinzufügens einer Website zu einer Sicherheitszone kennen.

Arbeiten in anderen Browsern: Chrome, Firefox und Safari

Andere Browser wie Google Chrome, Mozilla Firefox und Apple Safari implementieren das Konzept der Sicherheitszonen nicht. Wenn ein Browser die Cookies nicht in einem getrennten Speicher isoliert, treten die in diesem Artikel beschriebenen Probleme möglicherweise nicht auf. Wir empfehlen, dass Sie das apphost-Muster in Ihren Add-Ins befolgen. Auf diese Weise wird sichergestellt, dass Ihr Add-In in den erwähnten Browsern und Internet Explorer funktioniert, und zwar unabhängig davon, in welcher Sicherheitszone sich SharePoint befindet.

Share via