Verwenden des einmaligen Anmeldens (Single Sign-On, SSO) oder der ressourcenübergreifenden Ressourcenfreigabe (Cross-Origin Sharing, CORS) in Ihrem ereignisbasierten Outlook-Add-In oder Outlook-Add-In mit Spamberichterstattung

  • Artikel

Wenn ein Outlook-Add-In eine ereignisbasierte Aktivierung oder integrierte Spamberichterstattung implementiert, werden die Ereignisse in einer separaten Laufzeit ausgeführt. Um einmaliges Anmelden (Single Sign-On, SSO) zu konfigurieren oder externe Daten über cors (Cross-Origin Resource Sharing) in diesen Add-Ins anzufordern, müssen Sie einen bekannten URI konfigurieren. Über diese Ressource kann Office die Add-Ins identifizieren, einschließlich ihrer JavaScript-Dateien, die SSO- oder CORS-Anforderungen unterstützen.

Hinweis

Die Schritte in diesem Artikel gelten nur für Outlook-Add-Ins, die im klassischen Outlook unter Windows ausgeführt werden. Dies liegt daran, dass das klassische Outlook unter Windows eine JavaScript-Datei verwendet, während Outlook für Mac im Web und das neue Outlook unter Windows (Vorschau) eine HTML-Datei verwenden, die auf dieselbe JavaScript-Datei verweist. Weitere Informationen finden Sie unter Konfigurieren Ihres Outlook-Add-Ins für die ereignisbasierte Aktivierung und Implementieren eines integrierten Spamberichts-Add-Ins (Vorschau).

Auflisten zulässiger Add-Ins in einem bekannten URI

Um aufzulisten, welche Add-Ins mit SSO oder CORS arbeiten dürfen, erstellen Sie eine JSON-Datei, die jede JavaScript-Datei für jedes Add-In identifiziert. Hosten Sie dann diese JSON-Datei an einem bekannten URI. Ein bekannter URI ermöglicht die Spezifikation aller gehosteten JS-Dateien, die zum Abrufen von Token für den aktuellen Webursprung autorisiert sind. Dadurch wird sichergestellt, dass der Besitzer des Ursprungs die vollständige Kontrolle darüber hat, welche gehosteten JavaScript-Dateien in einem Add-In verwendet werden sollen und welche nicht, was z. B. Sicherheitsrisiken im Zusammenhang mit Identitätswechsel verhindert.

Das folgende Beispiel zeigt, wie Sie SSO oder CORS für zwei Add-Ins (eine Standard Version und Betaversion) konfigurieren. Sie können so viele Add-Ins wie nötig auflisten, je nachdem, wie viele Sie von Ihrem Webserver bereitstellen.

{
    "allowed":
    [
        "https://addin.contoso.com:8000/main/js/autorun.js",
        "https://addin.contoso.com:8000/beta/js/autorun.js"
    ]
}

Hosten Sie die JSON-Datei unter einem Speicherort namens .well-known im URI im Stammverzeichnis des Ursprungs. Wenn der Ursprung beispielsweise ist https://addin.contoso.com:8000/, ist der bekannte URI https://addin.contoso.com:8000/.well-known/microsoft-officeaddins-allowed.json.

Der Ursprung bezieht sich auf ein Muster von Schema + Unterdomäne + Domäne + Port. Der Name des Speicherorts muss sein .well-known, und der Name der Ressourcendatei muss sein microsoft-officeaddins-allowed.json. Diese Datei muss ein JSON-Objekt mit einem Attribut namens allowed enthalten, dessen Wert ein Array aller JavaScript-Dateien ist, die für SSO für ihre jeweiligen Add-Ins autorisiert sind.

Wenn Ihr Add-In SSO implementiert, können Sie nach dem Konfigurieren des bekannten URI die getAccessToken()-API aufrufen, um ein Zugriffstoken mit der Identität des Benutzers abzurufen.

Wichtig

Während OfficeRuntime.auth.getAccessToken sie Office.auth.getAccessToken die gleiche Funktionalität zum Abrufen eines Zugriffstokens ausführen, empfiehlt es sich, in Ihrem ereignisbasierten Add-In oder Spamberichterstellung (Vorschau) aufzurufen OfficeRuntime.auth.getAccessToken . Diese API wird in allen Outlook-Clientversionen unterstützt, die ereignisbasierte Aktivierung, integrierte Spamberichterstattung und einmaliges Anmelden unterstützen. Office.auth.getAccessToken Andererseits wird nur in Outlook unter Windows ab Version 2111 (Build 14701.20000) unterstützt.

Siehe auch