introduction
Dans le post précédent sur le thème de la sécurité basée sur les jetons, nous avons créé un Point de terminaison de l’API et protégé (en utilisant Autoriser attribut) avec IdentitéServeur. Ensuite, nous avons mis en place une application Angular simple avec un AuthService utiliser oidc-client une bibliothèque. Nous avons également créé quelques composants angulaires à la fin du post précédent, ainsi que deux boutons pour connexion/déconnexion fins dans appComponent, puis câblé la méthode suivante avec des événements de clic :
Aujourd’hui, nous allons continuer à partir du message précédent et terminer le processus de connexion/déconnexion. Nous verrons comment la bibliothèque cliente OIDC permet de mettre en œuvre très facilement les flux de redirection complexes prêts à l’emploi.
Alors, commençons et complétons le Se déconnecter code de la méthode en premier :
Comme vous pouvez le remarquer, depuis AppComponent Se déconnecter() méthode, nous déléguons simplement le travail à authService, qui utilisera Client OIDC bibliothèque pour que cela se produise. Regardons cela ensuite.
Achèvement du processus de connexion/déconnexion
À partir des boutons de l’interface utilisateur AppComponent, nous appelons des méthodes dans AuthService. Ici encore, nous appelons simplement des méthodes appropriées sur gestionnaire d’utilisateurs objet et qui fera tout le gros du travail pour nous :
Remarquez, le mot Réorienter dans les deux méthodes. Oui, ce code redirigera l’utilisateur vers IDP, où il/elle sera connecté/déconnecté au niveau IDP, et une fois cela terminé, l’utilisateur est redirigé vers l’application angulaire.
Gestion des rappels de redirection
Lorsque l’utilisateur est redirigé vers l’application angulaire, nous devons ajouter du code angulaire supplémentaire pour permettre à l’application angulaire de gérer la connexion/déconnexion processus d’achèvement.
Pour cela, j’ai créé les deux méthodes suivantes dans AuthService.ts:
Le code est explicite : nous appelons des méthodes appropriées sur gestionnaire d’utilisateurs objet de gérer le Rediriger les rappels. Donc TerminerConnexion sera appelé (en utilisant connexion-rappel.component, comme nous le verrons plus loin dans cet article) à la fin du connexion traiter (après que l’utilisateur ait entré le nom d’utilisateur/mot de passe sur l’IDP). Cette méthode génère également une notification sur la connexion de l’utilisateur.
Semblable à cela, terminerDéconnexion sera appelé à la fin de la processus de déconnexion (à l’aide de déconnexion-rappel.component, que nous verrons ensuite). Ce code s’éclaircit également utilisateur propriété sur authService.
Composants de rappel de connexion/déconnexion
Voici les composants pour gérer les rappels de connexion/déconnexion. IDP redirigera les utilisateurs vers ces composants dans le cadre du flux d’autorisation :
Le code suivant montre Se connecterRappel composant:
Comme vous pouvez le voir, nous appelons le completeLogin() méthode, que nous avons créée précédemment dans AuthService, et une fois terminé, nous dirigeons l’utilisateur vers racine URL (en supprimant également signinRedirect de la pile de navigation arrière du navigateur). Avis, pour le modèle, c’est juste un div vide.
Ensuite, voyons le code pour le rappel de déconnexion composant:
Ceci est très similaire au composant SigninCallback, un div vide, et terminerDéconnexion appel de méthode.
À ce stade, notre fonctionnalité de connexion/déconnexion est en place. Maintenant, configurons STS pour autoriser le client angulaire en ajoutant client informations comme indiqué ci-après.
Configurer IDP avec les informations client angulaires
Voici la configuration du client (Config.cs) dans l’IDP :
Nous avons discuté de toutes ces informations dans les articles précédents de cette série. Avis avec le RedirectionUris et PostLogoutRedirectUris, nous devons créer ces routes dans notre application angulaire et connecter et déconnecter les composants de rappel que nous avons créés précédemment afin que les redirections puissent se produire comme prévu.
Routes angulaires pour les URI de redirection
Mettons à jour les informations de routage dans l’application angulaire :
Notez que les chemins sont configurés comme configurés dans IDP et les composants que nous avons créés précédemment pour le processus de connexion/déconnexion. C’est ainsi qu’ils se sont tous câblés et travaillent ensemble pour mettre en œuvre le flux.
Tester l’application
Testons l’application, en exécutant des projets .NET Core (IDP, API, etc.) et une application Angular. Si nous naviguons jusqu’à l’URI racine de l’application angulaire, l’écran suivant apparaît :
Maintenant, cliquez sur le connexion bouton et nous sommes redirigés vers IDP (notez la barre d’adresse):
Ici, entrez le nom d’utilisateur et le mot de passe (vous pouvez utiliser les utilisateurs de test que nous avons configurés dans les messages précédents) et cliquez sur le bouton Connexion bouton. Nous sommes redirigés vers l’application Angular comme indiqué ci-dessous :
Ainsi, notre flux de connexion/déconnexion fonctionne comme prévu. Si nous ouvrons la fenêtre du navigateur (stockage de session), nous pouvons voir que les informations utilisateur suivantes sont disponibles :
Maintenant, quand je clique sur le Se déconnecter bouton, l’utilisateur est redirigé vers IDP à des fins de déconnexion :
Autoriser les appels à l’API
Nous pouvons nous connecter/déconnecter avec succès. Connectons-nous à nouveau et essayons d’accéder à la page Produits. Vous remarquerez que nous ne sommes toujours pas en mesure de voir les données des produits et que les fenêtres de la console nous montrent un 401 Erreur:
Cela se produit même si nous avons jeton d’accès d’IDP, nous ne l’avons pas encore transmis en tant qu’en-tête HTTP à l’API lors des appels HTTP. Cela implique généralement l’introduction d’un intercepteur HTTP. Nous aborderons cela dans le prochain article, ainsi que d’autres améliorations.
Vous pouvez télécharger le code source à partir de ce référentiel git. Nous continuerons dans le prochain post. Si vous avez des commentaires ou des questions, faites-le moi savoir. Jusqu’à la prochaine fois, Happy Coding.