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
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 auf Mac im Web und das neue Outlook unter Windows 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.
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 (hauptversion 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
. Zur Verdeutlichung soll diese Datei in Ihrem Office-Web-Add-In gehostet werden, nicht auf dem Webserver, an den Sie eine CORS-Anforderung senden möchten. Ein Beispiel für die Verwendung des empfohlenen Speicherorts finden Sie im Outlook-Add-in-SSO-events-Beispiel .
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 im klassischen Outlook unter Windows ab Version 2111 (Build 14701.20000) unterstützt.
Siehe auch
Office Add-ins