Upgrade von MSAL Angular v4 auf v5

MSAL Angular v5 erfordert eine Mindestversion von Angular 19 und legt die Unterstützung für Angular 15, 16, 17 und 18 ab.

Informationen zur Browserunterstützung und zu weiteren wichtigen Änderungen in der zugrunde liegenden @azure/msal-browserBibliothek finden Sie im MSAL Browser v4-zu-v5-Migrationsleitfaden.

Unterbrechen von Änderungen in @azure/msal-angular@5

Exakte Übereinstimmung für protectedResourceMap

In msal-angular v5 verwendet der URL-Musterabgleich für protectedResourceMap Einträge standardmäßig strenge Abgleichsemantik. Der strenge Abgleich behandelt Muster-Metazeichen als Literale, beschränkt Übereinstimmungen auf die vollständige URL-Komponente und wendet Host-Wildcard-Regeln an, die sich nicht über Punkttrennzeichen hinweg erstrecken. Wenn Ihre v4-Konfiguration auf weniger striktes Abgleichsverhalten angewiesen war, aktualisieren Sie Ihre protectedResourceMap-Muster, um sie an den strikten Abgleich anzupassen, oder setzen Sie strictMatching auf false, um das bisherige Verhalten vorübergehend beizubehalten. Weitere Informationen finden Sie in den MSAL Interceptor-Dokumenten .

Warning

Diese Änderung kann sich auch auf kleinere v5-Upgrades auswirken. Wenn strenger Abgleich in der v5-Minor-Version, die Sie ursprünglich verwendet haben (z. B. 5.0.x), noch nicht die Standardeinstellung war, kann ein Upgrade auf eine spätere v5-Minor-Version (z. B. 5.1.x), in der strenger Abgleich standardmäßig aktiviert ist, die Token-Zuordnung unbemerkt unterbrechen. Das Hauptsymptom ist identisch: 401-Fehler — es wird jetzt eine Laufzeitwarnung ausgegeben, wenn strictMatching nicht explizit konfiguriert ist, aber der Abgleichfehler selbst wird weiterhin nicht gemeldet, und der Header Authorization wird nicht mehr angehängt.

Schnellcheckliste

  1. Überprüfen Sie Ihre protectedResourceMap Schlüssel. Schlüssel, die bare Basis-URLs (z. B. https://api.example.com) ohne Wildcards oder Unterpfade sind, stimmen nicht mehr mit Anforderungen an Unterpfade dieser URL überein. Sehen Sie sich häufige Fehlermuster an.
  2. Aktualisieren Sie Schlüssel, um genaue Pfade oder Wildcards zu verwenden. Jeder Schlüssel sollte entweder mit der genauen URL übereinstimmen, die Ihre Anwendung anfordert, oder ein /* Wildcardsuffix verwenden, um Teilpfade abzugleichen. Weitere Informationen finden Sie unter "Fixoptionen".
  3. Wenn Ihre Schlüssel zur Laufzeit dynamisch geladen werden, legen Sie sie als temporären sicheren Standardwert fest strictMatching: false . Siehe Anleitungen für umgebungsgesteuerte Konfigurationen.

Umgebungsgesteuert protectedResourceMap

Wenn Ihre protectedResourceMap Schlüssel aus Angular-environmentDateien, APP_INITIALIZER, JSON-Konfiguration oder platformBrowserDynamic stammen, legen Sie strictMatching: false während der Migration als sichere Standardeinstellung fest:

export function MSALInterceptorConfigFactory(): MsalInterceptorConfiguration {
  const protectedResourceMap = new Map<string, Array<string>>();
  protectedResourceMap.set(environment.apiConfig.uri, environment.apiConfig.scopes);

  return {
    interactionType: InteractionType.Redirect,
    protectedResourceMap,
    // TODO: Remove once protectedResourceMap keys are updated to use
    // exact paths or wildcard patterns (e.g. "https://api.example.com/*").
    strictMatching: false,
  };
}

Sobald alle Schlüssel auf exakte Pfade oder Platzhalter migriert wurden, entfernen Sie strictMatching: false (oder setzen Sie es auf true), um vom strengeren, sichereren Abgleichsverhalten zu profitieren. Weitere Informationen finden Sie in den Anleitungen zu umgebungsgesteuerten Konfigurationen .

logout() wurde entfernt

logout() wurde entfernt. Verwenden Sie stattdessen logoutRedirect() oder logoutPopup().

// BEFORE (v4)
this.authService.logout();

// AFTER (v5)
this.authService.logoutRedirect();
// or
this.authService.logoutPopup();

Weitere Änderungen in @azure/msal-angular@5

inject(TOKEN)-Syntax

MSAL_INSTANCE, MSAL_GUARD_CONFIG, MSAL_INTERCEPTOR_CONFIG und MSAL_BROADCAST_CONFIG werden jetzt zu Typen statt zu Zeichenfolgen aufgelöst, um die Syntax inject(TOKEN) zu unterstützen. Diese Änderung kann TypeScript-Fehler in Anwendungen ohne explizite Eingabe verursachen.

handleRedirectObservable()-Optionen

handleRedirectObservable() akzeptiert nun ein optionales HandleRedirectPromiseOptions-Objekt, das die navigateToLoginRequestUrl-Option enthält, die aus der Konfiguration in @azure/msal-browser@5 verschoben wurde. Weitere Details finden Sie in der Umleitungsdokumentation .

// BEFORE (msal-browser v4 configuration)
const msalConfig = {
  auth: {
    clientId: 'your-client-id',
    navigateToLoginRequestUrl: false // This option has moved
  }
};

// AFTER (msal-angular v5)
this.authService.handleRedirectObservable({
  navigateToLoginRequestUrl: false
}).subscribe();

Note

Das direkte Übergeben einer Hashzeichenfolge an handleRedirectObservable(hash) ist veraltet. Verwenden Sie stattdessen das Optionsobjekt: handleRedirectObservable({ hash: "#..." }).

Beispiele

Die folgenden Entwicklerbeispiele sind jetzt verfügbar:

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

  • Last updated on