Mise à niveau de MSAL Angular v1 vers v2

MSAL Angular v2 met à jour notre wrapper Angular avec la dernière version de MSAL Common et offre une prise en charge intégrée des versions modernes d’Angular (9 à 12) et de RxJS (6).

Ce guide montre les modifications nécessaires pour migrer une application existante de @azure/msal-angular v1 vers v2.

La documentation spécifiquement pour MSAL Angular v2 est disponible ici.

Installation

La première modification fondamentale de MSAL Angular v2 est qu’elle n’utilise plus le package principal msal , mais encapsule le @azure/msal-browser package en tant que dépendance homologue.

Tout d’abord, désinstallez toutes les versions précédentes de MSAL actuellement utilisées.

Pour installer @azure/msal-browser et @azure/msal-angular:

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

Modifications radicales dans @azure/msal-browser@2

@azure/msal-browser@2 inclut un certain nombre de changements cassants par rapport à msal@1.x. La plupart de ces éléments doivent être extraits de votre application, mais il existe quelques-uns qui nécessitent des modifications de code.

MsalModule.forRoot prend maintenant trois arguments

Auparavant, @azure/msal-angular acceptait deux objets de configuration via MsalModule.forRoot(), un pour la bibliothèque principale et un pour @azure/msal-angular. Cela a été modifié pour accepter une instance de MSAL, ainsi que deux objets de configuration spécifiques à Angular.

  1. Le premier argument est l’instance MSAL. Cela peut être fourni sous la forme d’une fabrique qui instancie MSAL, soit en transmettant l’instance de MSAL avec les configurations.
  2. Le deuxième argument est un MsalGuardConfiguration objet, qui spécifie le interactionType , ainsi qu’un facultatif authRequest et un objet facultatif loginFailedRoute.
  3. Le troisième argument est un MsalInterceptorConfiguration objet, qui contient les valeurs pour interactionType, a protectedResourceMapet facultatif authRequest. unprotectedResourceMap est devenu obsolète.

Pour plus d’informations, consultez notre documentation de configuration et nos documents spécifiques pour MsalInterceptor et MsalGuard . Vous pouvez également voir nos exemples mis à jour pour obtenir des exemples de transmission de ces objets de configuration.

Logger

  • Le logger est désormais défini via la configuration de l’instance MSAL, dans system.loggerOptions, qui inclut loggerCallback, piiLoggingEnabled et logLevel, au lieu d’une instance de logger. Le logger peut également être défini dynamiquement à l’aide de MsalService.setLogger(). Pour plus d’informations, consultez logger documentation et l’utilisation.

Modifications d'API

  • Les méthodes acquireToken et login acceptent désormais différents objets de requête comme paramètres. Pour plus d’informations, consultez la msal.service.ts .
  • Les événements de diffusion émettent désormais un objet EventMessage, au lieu de simples chaînes de caractères. Consultez l’exemple Angular pour obtenir un exemple d’implémentation.
  • Les applications qui utilisent les méthodes Redirect doivent importer le MsalRedirectComponent et l’initialiser avec AppComponent dans leur fichier app.component.ts, lequel gérera toutes les redirections. Les applications ne parviennent pas à le faire doivent implémenter la handleRedirectObservable méthode (et l’exécuter sur chaque chargement de page), ce qui capture le résultat des opérations de redirection. Pour plus d’informations, consultez la documentation de redirection .

Intercepteur MSAL

  • Pour plus d’informations sur la configuration actuelle et les différences entre v1 et v2, MsalInterceptor.

MSAL Guard

  • Pour plus d’informations sur la configuration actuelle et les différences entre v1 et v2, MsalGuard.

Accounts

  • Nous vous recommandons de vous abonner à l’observable inProgress$ et de filtrer selon InteractionStatus.None avant de récupérer les informations du compte. Cela garantit que toutes les interactions sont terminées avant d’obtenir des informations sur le compte. Consultez notre exemple pour obtenir un exemple de cette utilisation.
  • Pour récupérer des comptes, nous vous recommandons d’utiliser getAccountByHomeId() et getAccountByLocalId(), disponibles dans l’instance MSAL. getAccount() est maintenant getAccountByUsername(), mais doit être un choix secondaire, car il peut être moins fiable et est pour la commodité uniquement.
  • getAllAccounts() est également disponible sur l’instance MSAL. Pour plus d’informations sur les méthodes de compte, consultez @azure/msal-browser.
  • De plus, vous pouvez désormais récupérer et définir les comptes actifs à l’aide de getActiveAccount() et setActiveAccount(). Pour plus d’informations, consultez notre FAQ .

Angular 9+ et rxjs@6

MSAL Angular s’attend maintenant à ce que votre application soit générée avec @angular/core@>=9, @angular/common@>=9rxjs@6, . Comme avec MSAL Angular v1, rxjs-compat n’est pas obligatoire.

Étapes:

  1. Installez les versions plus récentes d’Angular et rxjs : npm install @angular/core @angular/common rxjs
  2. Désinstallez rxjs-compat (en supposant qu’il n’est pas nécessaire pour d’autres bibliothèques) : npm uninstall rxjs-compat

Échantillons

Nous avons mis en place des exemples d’applications de base pour Angular 9, 10, 11 et 12. Ces exemples illustrent la configuration et l’utilisation de base, et seront améliorés et ajoutés de manière incrémentielle.

Consultez ici pour obtenir la liste des exemples MSAL Angular v2 et des fonctionnalités illustrées.

  • Last updated on