Upgrade von MSAL Angular v1 auf v2

MSAL Angular v2 bringt unseren Angular-Wrapper mit der neuesten Version von MSAL Common auf den neuesten Stand und bietet sofort einsatzbereite Unterstützung für moderne Versionen von Angular (9–12) und RxJS (6).

In diesem Handbuch werden Änderungen veranschaulicht, die zum Migrieren einer vorhandenen Anwendung von @azure/msal-angular v1 zu v2 erforderlich sind.

Dokumentation speziell für MSAL Angular v2 finden Sie hier.

Installation

Die erste grundlegende Änderung an MSAL Angular v2 besteht darin, dass das Kernpaket msal nicht mehr verwendet wird, sondern das @azure/msal-browser Paket als Peerabhängigkeit umschließt.

Deinstallieren Sie zunächst alle früheren Versionen von MSAL, die derzeit verwendet werden.

So installieren Sie @azure/msal-browser und @azure/msal-angular:

npm install @azure/msal-browser @azure/msal-angular@latest

Nicht abwärtskompatible Änderungen in @azure/msal-browser@2

@azure/msal-browser@2 enthält eine Reihe von nicht abwärtskompatiblen Änderungen von msal@1.x. Viele dieser Elemente sollten von Ihrer Anwendung abstrahiert werden, aber es gibt einige, die Codeänderungen erfordern.

MsalModule.forRoot akzeptiert jetzt drei Argumente.

Zuvor akzeptierte @azure/msal-angular über MsalModule.forRoot() zwei Konfigurationsobjekte, eines für die Kernbibliothek und eines für @azure/msal-angular. Dies wurde geändert, um eine Instanz von MSAL sowie zwei Angular-spezifische Konfigurationsobjekte zu übernehmen.

1. Das erste Argument ist die MSAL-Instanz. Dies kann entweder als Factory bereitgestellt werden, die MSAL instanziiert, oder indem die MSAL-Instanz zusammen mit den Konfigurationen übergeben wird.
2. Das zweite Argument ist ein MsalGuardConfiguration Objekt, das sowohl das interactionType als auch ein optionales authRequest und ein optionales loginFailedRouteObjekt angibt.
3. Das dritte Argument ist ein MsalInterceptorConfiguration Objekt, das die Werte für interactionType, a protectedResourceMapund optional authRequestenthält. unprotectedResourceMap ist veraltet.

Weitere Informationen finden Sie in unserem Konfigurationsdokument und spezifischen Dokumenten für MsalInterceptor und MsalGuard . In unseren aktualisierten Beispielen finden Sie auch Beispiele für das Übergeben dieser Konfigurationsobjekte.

Logger

• Das logger wird jetzt über Konfigurationen für die MSAL-Instanz unter system.loggerOptions festgelegt, die ein loggerCallback, piiLoggingEnabled und logLevel umfassen, anstelle einer Instanz eines logger. Das logger kann auch dynamisch mithilfe von MsalService.setLogger() festgelegt werden. logger documentation Weitere Informationen und Beispiele für die Verwendung finden Sie hier.

API-Änderungen

• Die acquireToken Methoden login verwenden jetzt unterschiedliche Anforderungsobjekte als Parameter. Weitere Informationen finden Sie im msal.service.ts .
• Übertragungsereignisse geben jetzt ein EventMessage Objekt anstelle von Zeichenfolgen aus. Ein Beispiel für die Implementierung finden Sie im Angular-Beispiel .
• Anwendungen, die Redirect-Methoden verwenden, sollten MsalRedirectComponent und Bootstrap zusammen mit AppComponent in ihre app.component.ts importieren; diese übernehmen alle Weiterleitungen. Anwendungen, die dies nicht tun können, sollten die Methode handleRedirectObservable implementieren (und sie bei jedem Laden der Seite ausführen), die das Ergebnis von Umleitungsvorgängen erfasst. Weitere Details finden Sie in der Umleitungsdokumentation .

MSAL Interceptor

• Bitte lesen Sie unsere MsalInterceptor-Dokumentation für weitere Details zur Konfiguration des aktuellen MsalInterceptor und zu den Unterschieden zwischen v1 und v2.

MSAL Guard

• Bitte lesen Sie unsere MsalGuard-Dokumentation für weitere Details zur Konfiguration des aktuellen MsalGuard und zu den Unterschieden zwischen v1 und v2.

Accounts

• Wir empfehlen, das inProgress$ Observable zu abonnieren und nach InteractionStatus.None zu filtern, bevor Kontoinformationen abgerufen werden. Dadurch wird sichergestellt, dass alle Interaktionen abgeschlossen wurden, bevor Kontoinformationen erhalten werden. Ein Beispiel für diese Verwendung finden Sie in unserem Beispiel .
• Beim Abrufen von Konten empfehlen wir die Verwendung von getAccountByHomeId() und getAccountByLocalId(), die auf der MSAL-Instanz verfügbar sind. getAccount() ist jetzt getAccountByUsername(), aber sollte eine sekundäre Wahl sein, da sie möglicherweise weniger zuverlässig ist und nur zur Bequemlichkeit ist.
• getAllAccounts() ist auch in der MSAL-Instanz verfügbar. Weitere Informationen zu Kontomethoden finden Sie in der Dokumentation@azure/msal-browser.
• Darüber hinaus können Sie jetzt aktive Konten mit getActiveAccount() und setActiveAccount() abrufen und festlegen. Weitere Informationen finden Sie in unseren HÄUFIG gestellten Fragen .

Angular 9+ und rxjs@6

MSAL Angular erwartet jetzt, dass Ihre Anwendung mit @angular/core@>=9, @angular/common@>=9, rxjs@6 erstellt wird. Wie bei MSAL Angular v1 ist rxjs-compat nicht erforderlich.

Schritte:

1. Installieren Neuerer Versionen von Angular und rxjs: npm install @angular/core @angular/common rxjs
2. Deinstallieren rxjs-compat (vorausgesetzt, es ist für andere Bibliotheken nicht erforderlich): npm uninstall rxjs-compat

Beispiele

Wir haben grundlegende Beispielanwendungen für Angular 9, 10, 11 und 12 zusammengestellt. Diese Beispiele veranschaulichen die grundlegende Konfiguration und Verwendung und werden inkrementell verbessert und hinzugefügt.

Hier finden Sie eine Liste der MSAL Angular v2-Beispiele und der gezeigten Features.