Maison > interface Web > js tutoriel > Analyse des problèmes courants dans la bibliothèque proxy http http-proxy dans nodejs

Analyse des problèmes courants dans la bibliothèque proxy http http-proxy dans nodejs

不言
Libérer: 2018-08-13 17:37:31
original
3114 Les gens l'ont consulté

Le contenu de cet article concerne l'analyse des problèmes courants dans la bibliothèque de proxy http http-proxy dans nodejs. Il a une certaine valeur de référence. Les amis dans le besoin peuvent s'y référer.

http-proxy

http-proxy est une bibliothèque de proxy http nodejs, qui a été intégrée par webpack-dev-server et utilisée comme proxy. La raison en est qu'aujourd'hui, alors que la séparation du front-end et du back-end est populaire, si nous devons ajuster localement l'interface API back-end sans configurer le nom d'hôte, ce sera inévitablement une requête inter-domaines. En raison des restrictions de sécurité inter-domaines du navigateur, l'appel est bloqué, le proxy local est donc devenu indispensable pour un environnement de développement local.

'/saasapi/*': {
    target: 'http://ebk.17u.cn',
},
Copier après la connexion

Cela signifie probablement rediriger la requête ajax commençant par saasapi vers http://ebk.17u.cn

Il n'y a aucun problème de développement local Si vous utilisez également le serveur nodejs en ligne, s'il vous arrive de configurer. it, Agent, des problèmes inattendus sont survenus lors du déploiement en ligne~

Le backend nginx est configuré avec un proxy inverse

Le nom de domaine principal d'un site Web est 17u.cn si plusieurs API sont déployées sur. le service backend, alors son service API peut ressembler à ceci

主域名 二级域名1 二级域名2 二级域名3
17u.cn ebk.17u.cn ebk2.17u.cn ebk3.17u.cn

Le front-end déploie également 3 services nodejs, et configure également 3 proxys. Après l'avoir déployé en ligne, nous avons constaté que la requête pointe toujours vers le premier nom de domaine de deuxième niveau et que les autres noms de domaine de deuxième niveau ne sont pas accessibles.

Je ne peux m'empêcher de penser à toi !

Plus tard, j'ai soigneusement vérifié les informations http et découvert qu'après l'envoi des requêtes ajax de plusieurs services au serveur, le nom d'hôte était le nom de domaine du navigateur et la configuration du proxy inverse de nginx était transférée en fonction sur le nom d'hôte. Étant donné que notre nom d'hôte n'est pas familier à nginx, il est transmis par défaut au premier service par défaut.

J'ai vérifié la configuration du proxy http, haha, en effet il existe une telle configuration modifiée, faites juste un léger changement.

'/saasapi/*': {
    target: 'http://ebk.17u.cn',
    changeOrigin: true
},
Copier après la connexion

changeOrigin: trueCela signifie simplement changer le nom d'hôte pour qu'il soit cohérent avec la cible. De cette façon, le backend nginx peut transférer normalement.

Le backend est configuré avec le chemin du cookie

L'API backend configure non seulement le nom de domaine de deuxième niveau, mais configure également le répertoire de deuxième niveau. Les services déployés sur le front-end. nécessitent le répertoire de deuxième niveau.

L'adresse API devient comme ceci :

ebk.17u.cn/saasapi
Copier après la connexion

Adresse frontale :

trans.17u.cn/saas
Copier après la connexion

Ajustez la configuration du proxy en conséquence

'/saas/saasapi/*': {
    target: 'http://ebk.17u.cn',
    changeOrigin: true,
    rewrite: path => path.replace(/^\/saas\/saasapi\/cxy/, '/saasapi')
},
Copier après la connexion

De cette façon, l'enfant a l'air normal, mais quel est le problème ? Le backend définit également le chemin des cookies définis après la connexion : Path='/saasapi'.

Un problème survient. trans.17u.cn/saasLe cookie ci-dessous /saasapi ne peut pas être lu sous le nom de domaine actuel. Par conséquent, la connexion frontale passe à chaque fois, mais l'API ne peut pas être ajustée normalement. fois qu'il est appelé, il échoue. L'invite n'est pas connectée.

Si vous avez des questions, veuillez d'abord consulter la documentation.

J'ai quand même trouvé une solution

cookiePathRewrite: { '/saasapi': '/saas/saasapi' }
Copier après la connexion

Réécrivez simplement le chemin du cookie. De même, si l'interface backend précise le domaine du cookie, il existe toujours une solution

cookieDomainRewrite
Copier après la connexion

Il existe d'autres réécritures, qui devraient être plus faciles à utiliser.

ps : En train de résoudre le problème, j'ai constaté que la modification échouait toujours. J'ai déjà soupçonné qu'il s'agissait d'un bug dans la bibliothèque. Plus tard, j'ai découvert que je devais effacer les cookies de Chrome.

Cliquez sur Application -> Cookie : Il n'est pas possible de supprimer les cookies suivants. Tous les cookies ne peuvent pas être effacés. Vous devez accéder à Application -> effacer le stockage et effacer les données du site. Succès final

Recommandations associées :

Analyse détaillée de la modularisation front-end en Js et comparaison de ses différences

Quelles sont les méthodes dans jQuery ?Méthodes couramment utilisées dans jQuery (avec code)

La différence et la conversion entre les objets jQuery et les objets natifs du DOM

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!

Étiquettes associées:
source:php.cn
Déclaration de ce site Web
Le contenu de cet article est volontairement contribué par les internautes et les droits d'auteur appartiennent à l'auteur original. Ce site n'assume aucune responsabilité légale correspondante. Si vous trouvez un contenu suspecté de plagiat ou de contrefaçon, veuillez contacter admin@php.cn
Tutoriels populaires
Plus>
Derniers téléchargements
Plus>
effets Web
Code source du site Web
Matériel du site Web
Modèle frontal