Dans l'article précédent, en utilisant le proxy Api dans Angular, nous avons traité du problème de l'interface de débogage commune locale et du proxy utilisé.
Nos interfaces sont écrites et traitées séparément. Dans les projets de développement réels, il existe de nombreuses interfaces, dont certaines nécessitent des informations de connexion, et d'autres non. Si chaque interface n’est pas gérée correctement, peut-on envisager d’intercepter et d’encapsuler la requête ? [Tutoriels associés recommandés : "Tutoriel Angular"]
Cet article sera implémenté.
Pour distinguer les environnements
, nous devons intercepter les services dans différents environnements. Lors de l'utilisation angular-cli
pour générer un projet, il a automatiquement distingué les environnements dans le répertoire app/enviroments
:
environnements. ├── Environment.prod.ts // Configuration utilisée dans l'environnement de production └── Environment.ts // Configuration utilisée dans l'environnement de développement
Modifions l'environnement de développement :
// enviroment.ts exporter l'environnement const = { URL de base : ', fabrication : faux };
baseUrl
est un champ ajouté devant la requête lorsque vous effectuez la requête. Il pointe vers l'adresse que vous souhaitez demander. Je n'ai rien ajouté. En fait, cela équivalait à ajouter le contenu de http://localhost:4200
.
Bien entendu, le contenu que vous ajoutez ici doit être ajusté pour correspondre au contenu ajouté sur votre proxy. Les lecteurs peuvent réfléchir et vérifier par eux-mêmes.
Nous
générons le service d'interception http-interceptor.service.ts
. la demande passera par ce service.
// http-intercepteur.service.ts importer {Injectable} depuis '@angular/core' ; importer { Événement HTTP, Gestionnaire HTTP, HttpInterceptor, // Intercepteur HttpRequest, // Request} de '@angular/common/http'; importer {Observable} depuis 'rxjs' ; importer { tap } depuis 'rxjs/operators' ; importer {environnement} depuis 'src/environments/environment' ; @Injectable({ fourni dans : 'root' }) classe d'exportation HttpInterceptorService implémente HttpInterceptor { constructeur() { } intercept(req : HttpRequest<any>, suivant : HttpHandler): Observable<HttpEvent<any>> { laissez secureReq : HttpRequest<any> = req ; secureReq = secureReq.clone({ URL : environnement.baseUrl + req.url }); retourner next.handle(secureReq).pipe( robinet( (réponse : n'importe lequel) => { // Traitez les données de réponse console.log(response) }, (erreur : n'importe laquelle) => { // Gérer les données d'erreur console.log (erreur) } ) ) } }
Pour que l'intercepteur prenne effet, il faut l'injecter sur app.module.ts
:
// app.module.ts importer { HttpClientModule, HTTP_INTERCEPTORS } depuis '@angular/common/http' ; // Importation du service d'intercepteur { HttpInterceptorService } depuis './services/http-interceptor.service' ; fournisseurs : [ // Injection de dépendances { fournir : HTTP_INTERCEPTORS, classe d'utilisation : HttpInterceptorService, multi : vrai, } ],
Vérification
à ce stade, nous avons implémenté avec succès l'intercepteur. Si vous exécutez npm run dev
, vous verrez le message suivant sur la console :
Pour vérifier si les informations d'identification du contenu sont requises pour accéder au contenu, j'ai utilisé ici l'interface [post] https://jimmyarea.com/api/private/leave/message
pour essayer d'obtenir l'erreur suivante :
Le backend a déjà traité le fait que cette interface nécessite des informations d'identification pour fonctionner, donc une erreur 401
est signalée directement.
Alors voici le problème. Une fois connectés, comment devons-nous apporter nos informations d'identification ?
Comme suit, nous modifions le contenu de l'intercepteur :
let secureReq: HttpRequest<any> = req; //... // Utilisez localhost pour stocker les informations d'identification de l'utilisateur dans l'en-tête de la requête if (window.localStorage.getItem('ut')) { laissez jeton = window.localStorage.getItem('ut') || secureReq = secureReq.clone({ en-têtes : req.headers.set('jeton', jeton) }); } // ...
La période de validité de ce certificat oblige les lecteurs à juger si la période de validité est valide lors de l'entrée dans le système, puis à envisager de réinitialiser la valeur de localstorage
, sinon des erreurs seront toujours signalées. C'est également très simple. l'encapsulation du localstorage
est pratique à utiliser Oui ~
[Fin]