Migrieren von MSAL v2.x zu MSAL v3.x

Wenn Sie mit MSAL noch nicht fertig sind, sollten Sie hier beginnen.

Wenn Sie von MSAL v1.x stammen, sollten Sie dieses Handbuch zuerst überprüfen, um zu MSAL v2.x zu migrieren, und führen Sie dann die nächsten Schritte aus.

Wenn Sie von MSAL v2.x stammen, können Sie diesem Leitfaden folgen, um Ihren Code für die Verwendung von MSAL v3.x zu aktualisieren.

Bahnbrechende Änderungen

Instanziierung einer Anwendung

In MSAL v2.x haben Sie wie folgt eine Anwendungsinstanz erstellt:

import { PublicClientApplication } from "@azure/msal-browser";

const msalConfig = {
    auth: {
        clientId: 'your_client_id'
    }
};

const msalInstance = new PublicClientApplication(msalConfig);

In MSAL v3.x müssen Sie auch das Anwendungsobjekt initialisieren. Es stehen ihnen mehrere Optionen zur Verfügung:

Option 1:

Instanziieren Sie ein PublicClientApplication Objekt, und initialisieren Sie es danach. Die initialize Funktion ist asynchron und muss aufgelöst werden, bevor andere MSAL.js-APIs aufgerufen werden.

import { PublicClientApplication } from "@azure/msal-browser";

const msalConfig = {
    auth: {
        clientId: 'your_client_id'
    }
};

const msalInstance = new PublicClientApplication(msalConfig);
await msalInstance.initialize();

Option 2:

Rufen Sie die createPublicClientApplication statische Methode auf, die ein initialisiertes PublicClientApplication Objekt zurückgibt. Beachten Sie, dass diese Funktion asynchron ist.

import { PublicClientApplication } from "@azure/msal-browser";

const msalConfig = {
    auth: {
        clientId: 'your_client_id'
    }
};

const msalInstance = await PublicClientApplication.createPublicClientApplication(msalConfig);

Anspruchsbasierte Zwischenspeicherung

In MSAL v2.x wird beim Hinzufügen von Claims zu einer Anfrage standardmäßig ein Hash der Zeichenfolge der angeforderten Claims zum Token-Cache-Schlüssel hinzugefügt. Dies bedeutet, dass MSAL 2.x Token basierend auf Ansprüchen standardmäßig zwischenspeichert und abgleicht. In MSAL v3.x ist dieses Verhalten nicht mehr der Standardwert. MSAL v3.x-Standardverhalten besteht darin, zum Netzwerk zu wechseln, um ein Token jedes Mal zu aktualisieren, wenn Ansprüche angefordert werden, unabhängig davon, ob das Token zuvor zwischengespeichert wurde und noch gültig ist. Anschließend überschreibt das empfangene Token nach dem Zugriff auf das Netzwerk das zwischengespeicherte Token, falls später eine stille Anfrage ohne Claims ausgeführt wird. Um das anspruchsbasierte Caching in MSAL v3.x zu aktivieren und dasselbe Verhalten wie in MSAL v2.x beizubehalten, müssen Entwickler das Konfigurationsflag cacheOptions.claimsBasedCachingEnabled verwenden, das im Konfigurationsobjekt der Clientanwendung auf „true“ gesetzt ist:

const msalConfig = {
    auth: {
        ...
    },
    ...
    cache: {
        claimsBasedCachingEnabled: true
    }
}

const msalInstance = new msal.PublicClientApplication(msalConfig);
await msalInstance.initialize();

Alle anderen APIs sind abwärtskompatibel mit MSAL v2.x. Es wird empfohlen, einen Blick auf das Standardbeispiel zu werfen, um ein funktionsfähiges Beispiel für MSAL v3.0 zu sehen.

Krypto

MSAL v3.x stellt die Unterstützung für die native Kryptografie von IE11 window.msCrypto und die Microsoft Research JavaScript Cryptography Library (MSR crypto) window.msrCrypto zugunsten der nativen Browser-Krypto-API window.crypto ein. Krypto-Optionen config.system.cryptoOptions , die für MSR-Krypto verwendet wurden, werden nicht mehr unterstützt.

Wichtige Änderungen

Browserunterstützung

MSAL.js unterstützt die folgenden Browser nicht mehr:

• IE 11
• Edge (Legacy)

Paketabhängigkeiten

Die TypeScript-Version wurde von 3.8.3 auf 4.9.5 angehoben.

Compileroptionen

Modul-/Zielversionen wurden jeweils von es6/es5 auf es2020/es2020 erhöht.

CDN

MSAL.js wird nicht mehr auf einem CDN gehostet. Weitere Informationen finden Sie in diesem Dokument .