Préface
Étant donné qu'Angular est une application à une seule page, la plupart des ressources seront chargées dans le navigateur depuis le début, vous devez donc accorder plus d'attention au moment de la vérification et vous assurer que seuls les utilisateurs qui ont réussi la vérification peuvent voir l'interface correspondante.
L'authentification de cet article fait référence à la façon de déterminer si l'utilisateur s'est connecté et s'assure que les besoins de vérification du serveur peuvent être satisfaits dans chaque communication avec le serveur. Notez qu'il n'inclut pas le jugement pour savoir s'il existe une autorité spécifique.
Pour la connexion, il s'agit principalement d'accepter l'entrée du nom d'utilisateur et du mot de passe de l'utilisateur , de le soumettre au serveur pour la vérification , de traiter la réponse de vérification et de créer des données d'authentification du côté du navigateur .
Deux façons de mettre en œuvre l'authentification de l'identité
À l'heure actuelle, il existe deux principales catégories de méthodes pour mettre en œuvre l'authentification de l'identité:
Cookies
Les pages Web traditionnelles du navigateur utilisent des cookies pour vérifier l'identité. En fait, dans la couche d'application du navigateur, il n'y a essentiellement pas besoin de s'inquiéter de la vérification de l'identité. Les paramètres des cookies sont complétés par le serveur. Lors de la soumission de la demande, le navigateur joigne automatiquement les informations de cookie correspondantes. Par conséquent, dans le code JavaScript, il n'est pas nécessaire d'écrire du code spécial pour cela. Mais chaque fois que je demande, j'apporterai toutes les données de cookies.
Avec l'application de CDN et la montée progressive des appareils mobiles, les cookies sont de plus en plus incapables de répondre aux besoins complexes d'authentification multi-domaines.
Clé
En fait, l'authentification par clé n'a pas seulement émergé récemment, elle a été là, même plus longtemps que l'histoire des cookies. Lorsque le navigateur demande le serveur, il attache la clé à la demande d'une manière spécifique, comme dans les en-têtes de la demande. Pour ce faire, un code client spécial doit être rédigé pour la gestion.
La norme de clé Web JSON récemment émergente （JSON Web Token） est une authentification typique utilisant une clé.
Dans les applications Web, si vous construisez des API, vous devez donner la priorité à l'utilisation de la méthode clé.
Connexion de traitement
La connexion est la première étape de la vérification de l'identité. Ce n'est qu'en enregistrant que les données de vérification d'identité correspondantes peuvent être organisées.
Besoin d'utiliser une page de connexion distincte?
Il existe deux façons de gérer les pages de connexion:
Une page de connexion distincte sautera vers l'application à une seule page une fois la connexion terminée. Cela permet un contrôle d'accès des ressources de l'application à une seule page pour empêcher les utilisateurs non-loginnes d'accéder et convient aux scénarios d'application des outils d'arrière-plan ou de gestion. Mais cela réduit en fait l'expérience utilisateur des applications à une seule page
Exécutez la connexion dans une seule application de page , qui est plus conforme au concept de conception d'une seule application de page et est plus adapté aux scénarios de produits populaires, car les personnes malveillantes peuvent toujours obtenir le code frontal de votre application de page unique.
Une page de connexion distincte
D'une manière générale, le but d'utiliser une page de connexion séparée est de protéger les pages qui sont sautées après la connexion contre les utilisateurs anonymes. Par conséquent, dans la page de connexion, un formulaire est construit et la méthode de soumission de la mention élogieuse traditionnelle (non ajax) est directement utilisée. Une fois que le backend valide le nom d'utilisateur et le mot de passe avec succès, le HTML de la page d'application unilatérale après la connexion.
Dans ce cas, vous pouvez placer directement les informations d'authentification dans le HTML de sortie, par exemple, vous pouvez utiliser Jade pour construire une page comme celle-ci:
<! - Dashboard.jade -> doctype htmlhtmlhtml head link (rel = "Stylesheet", href = "/ attets / app.e1c2c6ea9350869264da10de799dced1.css") script corpore. window.token =! {json.stringify (token)}; Script div.md-padding (UI-View) (src = "/ actifs / app.84b1e53df1b4b23171da.js")Une fois le nom d'utilisateur et la vérification du mot de passe réussi, le backend peut utiliser la méthode suivante pour rendre et sortir HTML:
return res.render ('Dashboard', {token: token});Une fois l'application angulaire lancée, elle peut communiquer avec l'authentification. Il garantit également que seuls les utilisateurs qui se sont connectés avec succès peuvent entrer dans cette page.
Organisations qui se connectent à une seule application de page
Pour les applications angulaires multi-vues, le routage est généralement utilisé. Dans la page, il y a généralement un menu de barre latérale fixe ou un menu de navigation supérieur, et la zone de texte est contrôlée par le module de routage.
L'exemple de code suivant utilise un matériau angulaire pour organiser la page et le module de routage utilise l'interface utilisateur. Lorsque l'application est ouverte, il y a une animation de chargement spéciale. Une fois le chargement terminé, la page affichée est utilisée par le contrôleur AppController . Pour les utilisateurs qui ne sont pas connectés, un formulaire de connexion sera affiché. Une fois la connexion terminée, la page est divisée en trois parties: l'une est la navigation supérieure au fil du fil , la seconde est le menu de la barre latérale , et l'autre est la partie principale du contrôle de l'itinéraire .
Le code est le suivant:
<body ng-app = "app" Layout = "row"> <div id = "Loading"> <! - Page de chargement invite -> </ div> <div flex disposition = "row" ng-coak ng-controller = "AppController" ng-init = "Load ()"> <div ng-if = "! iSuseraut <! - Loginform -> </ div> <div ng-if = "ISUSERAUTH" Flex Layout = "Row"> <MD-sidenav flex = "15" MD-IS-Locked-Open = "True"> <! - Sidebar Menu -> </ md-sidenav> <MD-CONTANT FLEX LAYOUT = "Column" Role = "Main"> <md-toolbar> </ md-toolbar> <md-content> <! - Routing -> <div ui-view> </div> </md-content> </md-content> </div> </div> </ody>
Pour le chargement d'animations, ils sont en dehors AppController et peuvent être cachés dans AppController . Cela atteint le chargement de la disparition après la charge de CSS / JavaScript.
Il y a une variable dans AppController isUserAuth Il est false lorsqu'il est initialisé. Lorsque les informations de session stockées localement sont valides ou, une fois la connexion terminée, cette valeur sera définie sur ture . En raison du contrôle de ng-if , le but de cacher le formulaire de connexion et d'affichage du contenu de l'application peut être atteint. Il convient de noter qu'en utilisant ng-if au lieu de ng-show/ng-hide ici, le premier supprimera et ajoutera vraiment des éléments DOM, tandis que le second ne modifiera que les attributs CSS d'un élément DOM. C'est très important. Ce n'est que de cette manière que nous pouvons nous assurer qu'après la connexion, le contenu de l'application à une seule page sera chargé pour empêcher le code du contrôleur de l'itinéraire actuel d'être exécuté directement avant de se connecter.
Pourquoi les clients cryptent-ils également les mots de passe
Un processus de connexion idéal basé sur le nom d'utilisateur et le mot de passe est le suivant:
1. Le côté du navigateur obtient le mot de passe entré par l'utilisateur, utilise un algorithme de hachage tel que MD5 pour générer un nouveau mot de passe de longueur fixe, comme md5(username + md5(md5(password))) , puis soumet la valeur de hachage du mot de passe et le nom d'utilisateur vers le backend
2. Le backend obtient le sel correspondant en fonction du nom d'utilisateur, utilise le nom d'utilisateur et la valeur de hachage de mot de passe, calcule un texte chiffré et recherche la base de données en fonction du nom d'utilisateur et du mot de passe
3. Si la requête réussit, générez la clé, renvoyez-la au navigateur et effectuez l'étape 4
4. Le backend génère un nouveau sel et génère un nouveau texte chiffré basé sur le nouveau sel et la valeur de hachage de mot de passe soumis par le navigateur. Mettre à jour le sel et le texte chiffré dans la base de données
Peut-être que 80% des personnes ne peuvent pas comprendre pourquoi une connexion est si compliquée. Cela peut nécessiter un article spécial pour expliquer clairement. Ici, je vais d'abord expliquer pourquoi le navigateur hache le mot de passe, et les raisons sont les suivantes:
1. Protégez le mot de passe de l'utilisateur de la source pour vous assurer que ce n'est qu'en effectuant des enregistrements clés que vous pouvez obtenir le mot de passe d'origine de l'utilisateur
2. Même si le réseau est écouté et que HTTPS n'est pas utilisé, le mot de passe volé n'est qu'après le hachage, ce qui peut affecter les données de l'utilisateur sur ce serveur au maximum et n'affecte pas d'autres sites Web qui utilisent le même mot de passe.
3. Même le propriétaire du serveur ne peut pas obtenir le mot de passe d'origine de l'utilisateur.
Cette approche rend le plus grand risque pour les utilisateurs et les données de l'application actuelle sont volées. La plage de pertes ne sera pas élargie et il n'y aura jamais de problèmes avec le CSDN ou d'autres flux.
Connectez-vous une notification réussie
Pour certaines applications, toutes les pages ne nécessitent pas que les utilisateurs se connectent. Ils ne peuvent avoir besoin de se connecter que lors de l'exécution de certaines opérations. Dans ce cas, après s'être connecté, toute la demande doit être informée. Cela vous permet d'utiliser la fonction de diffusion.
Le code simple est le suivant:
Angular .Module ('app') .Controller ('LoginController', ['$ Rootscope', LoginController]); fonction LoginController ($ Rootscope) {// Fonction appelée AfterLoginsuccess () {$ Rootscope. }}Dans d'autres contrôleurs, vous pouvez écouter cette diffusion et effectuer les opérations qui doivent être effectuées après le succès de la connexion, comme l'obtention d'une liste ou de détails:
$ scope. $ on ('user.login.success', fonction (manche, données) {// traitement});Informations sur l'authentification de l'identité
Après avoir enregistré avec succès, le serveur renvoie la clé et les demandes d'API suivantes doivent apporter la clé, et la réponse renvoyée par la demande doit également être vérifiée s'il s'agit d'une erreur concernant l'invalidité des informations d'identité. Cette série de travaux est assez lourde et devrait être terminée automatiquement.
sauvegarder
Il existe à peu près les moyens suivants de sauver la clé:
1.Cookies: Comme mentionné précédemment, cela n'est pas recommandé. En même temps, il a également une limite maximale de 4K
2.SessionStorage: La page onglet est valide. Une fois fermé ou une nouvelle page onglet ouverte, SessionStorage ne peut pas être partagée.
3.Localstorage: une méthode de stockage idéale. À moins que les données du navigateur ne soient nettoyées, les données stockées dans LocalStorage existeront toujours.
4. Service Angular Singleton: s'il est stocké dans l'application, les données seront perdues après rafraîchissement, et bien sûr, il ne peut pas être partagé entre les pages d'onglet.
Une meilleure approche est que les informations d'authentification sont stockées dans LocalStorage, mais elles sont initialisées dans le service Singleton d'Angular au début de l'application.
Ajouter des informations d'authentification à la demande
Le but des informations d'authentification d'identité est d'indiquer l'identité du serveur et d'obtenir des données. Par conséquent, des informations d'authentification supplémentaires sont requises dans la demande.
Dans les applications générales, les informations d'authentification sont placées dans les en-têtes de la demande. Si vous définissez les en-têtes un par un à chaque demande, ce sera trop long et laborieux. $httpProvider dans Angular fournit un interceptors intercepteur à travers lequel un traitement unifié de chaque demande et réponse peut être obtenu.
La façon d'ajouter un intercepteur est la suivante:
Angular .Module ('app') .config (['$ httpprovider', fonction ($ httpprovider) {$ httpprovider.interceptors.push (httpinterceptor);}]); La définition de HttpInterceptor est la suivante:
Angular .module ('app') .factory ('httpinterceptor', ['$ q', httpinterceptor]); fonction httpinterceptor ($ q) {return {// avant la demande émise, il peut être utilisé pour ajouter diverses informations d'authentification: fonction (config) {if (localstorage.token) {config.heders.token = localStorage.Token) {config.Heders.Token. } return config; }, // Une erreur s'est produite pendant que la demande est émise requestror: function (err) {return $ q.reject (err); }, // Réponse Réponse: fonction (res) {return res; }, // L'erreur de réponse renvoyée, y compris lorsque le backend renvoie la réponse, le code d'état HTTP de non 200 est défini: fonction (err) {return $ q.reject (err); }};}Les intercepteurs fournissent le traitement complet du cycle de vie de la demande à la réponse de retour, qui peut généralement être utilisée pour effectuer ce qui suit:
1. Ajouter des données aux demandes émises uniformément, comme l'ajout d'informations d'authentification
2.
3. Traitement de la réponse unifiée, tels que cache certaines données, etc.
4. Afficher la barre de progression de la demande
Dans l'exemple de code ci-dessus, lorsque localStorage inclut le token de valeur, une valeur token est ajoutée à la tête de chaque demande.
Échec et manipulation
Généralement, le backend doit définir le code d'état HTTP de réponse sur 401 lorsque token échoue, afin qu'elle puisse être gérée uniformément dans l'intercepteur responseError :
RéponseError: fonction (err) {if (-1 === err.status) {// Le serveur distant ne répond pas} else if (401 === err.status) {// L'erreur 401 est généralement utilisée pour l'échec de l'authentification. Cela dépend de l'erreur lancée par le backend lorsque l'authentification échoue} else if (404 === err.status) {// le serveur renvoie 404} return $ q.reject (err);}Résumer
En fait, tant que le code d'état renvoyé par le serveur n'est pas 200, responseError sera appelée. Ici, l'erreur peut être gérée uniformément et affichée.
Le contenu ci-dessus est lié à la connexion et à la vérification de l'identité dans les applications de développement angulaire. J'espère qu'il sera utile à tout le monde d'apprendre angulaire.