Utilisation réelle de l'en-tête X-Forwarded-Host?
J'ai trouvé des informations intéressantes sur les en-têtes X-Forwarded-*, y compris la section En-têtes de demande de proxy inverse de la documentation Apache, ainsi que le article de Wikipedia sur X-Forwarded-For .
Je comprends que:
X-Forwarded-Fordonne l'adresse du client qui s'est connecté au proxyX-Forwarded-Portdonne le port auquel le client s'est connecté sur le proxy (par exemple80ou443)X-Forwarded-Protoindique le protocole utilisé par le client pour se connecter au proxy (httpouhttps)X-Forwarded-Hostdonne le contenu de l'en-têteHostque le client a envoyé au proxy.
Tout cela a du sens.
Cependant, je n'arrive toujours pas à comprendre un cas d'utilisation réel de X-Forwarded-Host. Je comprends la nécessité de répéter la connexion sur un port différent ou en utilisant un schéma différent, mais pourquoi un serveur proxy modifierait-il l'en-tête Host lors de la répétition de la demande au serveur cible?
Si vous utilisez un service frontal tel que Apigee comme interface frontale pour vos API, vous aurez besoin de quelque chose comme X-FORWARDED-Host pour comprendre quel nom d'hôte a été utilisé pour se connecter à l'API, car Apigee est configuré avec Quel que soit votre DNS principal, nginx et votre pile d'applications ne voient l'en-tête de l'hôte que comme nom DNS principal, et non le nom d'hôte appelé en premier lieu.
Je peux vous dire un problème de la vie réelle, j'ai eu un problème en utilisant un portail IBM.
Dans mon cas, le problème était que le portail IBM avait un service de repos qui récupérait une URL pour une ressource, quelque chose comme: {"Url": " http://internal.Host.name/path " }
Que s'est-il passé? Simple. Lorsque vous accédez à l'intranet, tout fonctionne correctement car internalHostName existe mais ... lorsque l'utilisateur entre Internet, le proxy n'est pas en mesure de résoudre le nom d'hôte et le portail se bloque.
Le correctif pour le portail IBM consistait à lire l'en-tête X-FORWARDED-Host, puis à modifier la réponse comme suit: {"Url": " http://internet.Host.name/path " }
Voir que je mets internet et non interne dans la deuxième réponse.
Voici le scénario sur lequel j'ai travaillé aujourd'hui: Les utilisateurs accèdent à certains serveurs d'applications à l'aide de l'URL " https://neaturl.company.com " qui pointe vers un proxy inverse. Le proxy met alors fin à SSL et redirige les demandes des utilisateurs vers le serveur d'applications réel dont l'URL est " http://192.168.1.1:5555 ". Le problème est le suivant: lorsque le serveur d'applications avait besoin de rediriger l'utilisateur vers une autre page sur le même serveur en utilisant un chemin absolu, il utilisait cette dernière URL et les utilisateurs n'y avaient pas accès. L’utilisation de X-Forwarded-Host (+ X-Forwarded-Proto et X-Forwarded-Port) a permis à notre proxy de dire au serveur d’application l’utilisateur d’URL utilisé à l’origine et le serveur a donc commencé à générer le chemin absolu correct dans ses réponses.
Dans ce cas, il n'existait aucune option permettant au serveur d'applications de générer des URL absolues ni de le configurer manuellement pour "URL publique".
Un exemple pourrait être un proxy qui bloque certains hôtes et les redirige vers une page de blocage externe. En fait, je suis presque certain que mon filtre scolaire le fait…
(Et la raison pour laquelle ils pourraient ne pas simplement transmettre la Host d'origine en tant que Host est que certains serveurs [Nginx?] Refusent tout trafic vers la mauvaise Host.)
Pour la nécessité d'un «hôte x-transféré», je peux penser à un scénario d'hébergement virtuel dans lequel il y a plusieurs hôtes internes (réseau interne) et un proxy inverse installé entre ces hôtes et Internet. Si l'hôte demandé fait partie du réseau interne, celui-ci est résolu en adresse IP du proxy inverse et le navigateur Web envoie la demande au proxy inverse. Ce proxy inverse trouve l'hôte interne approprié et transmet la demande envoyée par le client à cet hôte. Ce faisant, le proxy inverse modifie le champ Hôte afin qu'il corresponde à l'hôte interne et définit l'hôte x-forward-Host sur l'hôte réel demandé par le client. Plus de détails sur le proxy inverse peuvent être trouvés dans cette page wikipedia http://en.wikipedia.org/wiki/Reverse_proxy .
Consultez cet article pour plus de détails sur l'en-tête x-forwarded-for et un script de démonstration python simple qui montre comment un serveur Web peut détecter l'utilisation d'un serveur proxy: x-forwarded-for a expliqué
X-Forwarded-Host vient de me sauver la vie. Les CDN (ou le proxy inverse si vous souhaitez accéder à des "arbres") déterminent quelle origine utiliser en-tête d'hôte avec laquelle un utilisateur vient à eux. Ainsi, un CDN ne peut pas utiliser le même en-tête d’hôte pour contacter l’origine, sinon le CDN irait à lui-même dans une boucle plutôt que d’aller à l’origine. Ainsi, le CDN utilise une adresse IP ou un nom de domaine complet factice comme en-tête de l'hôte, récupérant le contenu de l'origine. Désormais, l’Origine souhaitera peut-être savoir quel était l’en-tête de l’hôte (nom du site Web) auquel le contenu est demandé. Dans mon cas, une origine a servi 2 sites Web.
Un autre scénario consiste à attribuer une licence à votre application à une URL hôte, puis à équilibrer la charge sur n> 1 serveurs.