La vie réelle d'utilisation de la X-Forwarded-en-tête d'Hôte?
J'ai trouvé intéressant à lire sur le X-Forwarded-* en-têtes, y compris la Reverse Proxy En-Têtes De Requête section dans la documentation d'Apache, ainsi que la Article de wikipédia sur les X-Forwarded-For.
Je comprends que:
X-Forwarded-Fordonne l'adresse du client connecté au proxyX-Forwarded-Portdonne le port du client connecté sur le serveur proxy (par exemple80ou443)X-Forwarded-Protodonne le protocole le client a utilisé pour se connecter au proxy (httpouhttps)X-Forwarded-Hostdonne le contenu de laHosten-tête, le client envoie au serveur proxy.
Ces tous les sens.
Cependant, je n'arrive toujours pas à comprendre la vie réelle de cas d'utilisation de X-Forwarded-Host. Je comprends la nécessité de répéter la connexion sur un autre port ou à l'aide d'un schéma différent, mais pourquoi un serveur proxy jamais changer le Host d'en-tête lors de la répétition de la requête vers le serveur cible?
Vous devez vous connecter pour publier un commentaire.
Si vous utilisez un service frontal comme Apigee que le front-end de votre Api, vous aurez besoin de quelque chose comme X-FORWARDED-HÔTE de comprendre ce que le nom d'hôte utilisé pour se connecter à l'API, car Apigee se configure avec quel que soit votre backend DNS est, nginx et votre application à la pile seulement de voir l'en-tête d'Hôte en tant que back-end et DNS nom, pas au nom d'hôte qui a été appelé en premier lieu.
Hosten-tête du client sans être importuné par le serveur d'origine (comme la RFC dit qu'il devrait).Je peux vous dire que la vie réelle question, j'ai eu un problème à l'aide d'un IBM portal.
Dans mon cas, le problème était que le IBM portail dispose d'un service rest qui récupère l'url d'une ressource, quelque chose comme:
{"url":"http://internal.host.name/path"}
Ce qui s'est passé?
Simple, lorsque vous entrez à partir de l'intranet tout fonctionne bien parce que internalHostName existe, mais... quand à l'utilisateur d'entrer partir d'internet, puis le proxy n'est pas en mesure de résoudre le nom d'hôte et le portail se bloque.
Le correctif pour le IBM portail était de lire les X-FORWARDED-en-tête d'HÔTE, puis modifier la réponse à quelque chose comme:
{"url":"http://internet.host.name/path"}
Voir que j'ai mis internet et de ne pas interne dans la seconde réponse.
C'est le scénario, j'ai travaillé aujourd'hui:
Les utilisateurs d'accéder à certains serveur d'applications à l'aide de "https://neaturl.company.com" URL qui pointe vers un Proxy Inverse. Proxy puis termine SSL et redirige les demandes des utilisateurs de l'application serveur qui a l'URL de "http://192.168.1.1:5555". Le problème est lorsque le serveur d'application nécessaires pour rediriger l'utilisateur vers une autre page sur le même serveur à l'aide de chemin absolu, c'est à l'aide des derniers URL et les utilisateurs n'ont pas accès à cela. À l'aide de X-Forwarded-Hôte (+ X-Forwarded-Proto et X-Forwarded-Port) a permis à notre proxy dire serveur d'application qui l'URL de l'utilisateur utilisé à l'origine et donc le serveur a commencé à générer de corriger chemin d'accès absolu dans ses réponses.
Dans ce cas, il n'y a pas d'option pour arrêter le serveur d'application pour générer des Url absolues, ni le configurer pour le "bien public" url manuellement.
Un exemple pourrait être un proxy qui bloque certains hôtes et les redirige vers un bloc externe page. En fait, je suis presque certaine que mon école filtre est-ce que...
(Et la raison pour laquelle ils ne pourraient pas simplement passer sur l'original
HostcommeHostest parce que certains serveurs Nginx?] rejeter tout le trafic vers le malHost.)X-Forwarded-Hostà afficher "Vous ne pouvez pas vous connecter à xxx.com?Pour le besoin de "x-forwarded-hôte", je ne peux penser à un hébergement virtuel scénario où il y a plusieurs hôtes internes (réseau interne) et un proxy inverse assis entre les hôtes et de l'internet. Si l'hôte est une partie du réseau interne, l'hôte décide de le reverse proxy IP et le navigateur web envoie la requête au proxy inverse. Ce reverse proxy trouve la appropriée de l'hôte interne et transmet la requête envoyée par le client à cet hôte. En agissant de la sorte, le reverse proxy modifie le champ hôte pour correspondre à l'hôte interne et définit le x-de l'avant-hôte à l'hôte réel demandé par le client. Plus de détails sur le reverse proxy peut être trouvée dans cette page de wikipedia http://en.wikipedia.org/wiki/Reverse_proxy.
Vérifier ce post pour plus de détails sur x-forwarded-for-tête et une simple démo script python qui montre comment un serveur web peut détecter l'utilisation d'un serveur proxy: x-forwarded-for expliqué
X-Forwarded-Hôte juste sauvé ma vie. Les cdn (ou reverse proxy si vous voulez aller vers "les arbres") de déterminer l'origine de l'utilisation par l'Hôte de l'en-tête d'un utilisateur vient à eux avec. Ainsi, un CA peut pas utiliser le même en-tête d'Hôte pour contacter l'origine - dans le cas contraire, le CA irait de lui-même dans une boucle plutôt que d'aller à l'origine. Ainsi, le CA utilise l'adresse IP ou certains factice nom de domaine complet que l'en-tête d'Hôte récupérer le contenu à partir de l'origine. Maintenant, l'origine peut souhaiter savoir quel a été l'Hôte de l'en-tête (aka le nom du site) le contenu est demandé. Dans mon cas, une origine, servi 2 sites.
Un autre scénario, de l'immatriculation de votre application à l'hôte de l'URL que vous voulez pour équilibrer la charge entre n > 1 serveurs.