Comment obtenir l'adresse IP ou le nom d'hôte du navigateur?

Question

J'ai une application Web qui devrait se comporter différemment pour les utilisateurs internes que pour les utilisateurs externes. L'application Web est disponible sur Internet, et donc évidemment aussi pour les utilisateurs internes.

Tous les utilisateurs sont anonymes, non authentifiés, mais la page devrait afficher un rendu différent pour les utilisateurs internes que pour les utilisateurs externes. Ce que je fais dans mon code est l'utilisation Request.UserHostName puis Dns.GetHostEntry. Le résultat est ensuite comparé à un paramètre dans mon web.config (qui contient quelque chose comme *.mydomain.local). Si la comparaison donne un résultat positif, je rends le HTML que l'utilisateur interne devrait voir sinon je rends le code HTML que l'utilisateur externe devrait voir.

Cependant, mon problème est que je ne reçois pas toujours la valeur attendue de Request.UserHostName. sur le site de développement, je reçois le IP-number (?) de la machine exécutant le navigateur, mais sur le site du client, je ne reçois pas le IP-number de la machine de l'utilisateur, je reçois un autre IP-number. Les navigateurs n'ont aucun ensemble de proxies ou quelque chose comme ça.

Dois-je utiliser autre chose que Request.UserHostName?

Answer 1

Je recommande également d'utiliser des adresses IP. Je suis confronté à cette même situation en mettant en place un système d'authentification en ce moment et les conditions décrites par Epso et Robin M sont exactement ce qui se passe. Les utilisateurs externes qui viennent sur le site me donnent leur adresse IP réelle alors que tous les utilisateurs internes fournissent l'adresse IP de la passerelle (routeur) au sous-réseau privé sur lequel les serveurs Web sont assis.

Pour faire face à cela, je vérifie juste pour ce IP. Si j'obtiens l'IP de la passerelle, je fournis l'accès interne. Si je reçois autre chose, ils obtiennent l'externe qui nécessite une authentification supplémentaire dans mon cas. Dans le vôtre, cela signifierait simplement une interface différente.

Answer 2

Il peut y avoir un pare-feu qui effectue une sorte de NAT, pour permettre aux clients d'utiliser le nom DNS externe pour atteindre le serveur.

Le numéro IP que vous obtenez sur le site client est-il le même sur l'adresse IP client-serveur externe? Dans ce cas, vous pouvez coder en dur pour cette adresse IP. Tous les ordinateurs internes derrière ce pare-feu sembleront avoir la même adresse IP et vous pouvez les classer comme "internes".

Answer 3

Il semble que vous recevez une adresse IP publique. Obtenez l'utilisateur d'aller à http://www.myipaddress.com. Si c'est la même chose que l'adresse IP retournée à votre logiciel, c'est définitivement le cas. La seule solution que je puisse voir pour contourner ceci est soit de les faire se connecter à la machine contenant l'application asp.net via un VPN, soit d'utiliser un autre type d'authentification. Ce dernier est probablement la meilleure option.

Answer 4

Essayez Request.UserHostAddress, qui renvoie l'adresse IP du client. En supposant que votre réseau interne utilise des adresses IP réservées aux réseaux locaux, il devrait être relativement simple de vérifier si une adresse IP est interne ou externe.

Answer 5

Il semble qu'il existe un proxy entre les utilisateurs et le serveur sur le site du client (il n'a pas besoin d'être configuré dans le navigateur). Il peut s'agir d'un proxy interne ou externe en fonction de la configuration de votre réseau. J'éviterais d'utiliser le UserHostName pour ce qui est effectivement l'authentification car il est présenté par le navigateur qui traite la requête et serait facile à usurper. L'adresse IP serait beaucoup plus efficace car il est difficile d'usurper une adresse IP dans une connexion TCP/IP (et maintenir une connexion). C'est encore une authentification faible mais peut être suffisante dans ce scénario.

Même si vous utilisez une adresse IP, s'il existe un proxy NAT entre le client et le serveur, vous devrez peut-être accepter tout ce qui passe par ce proxy (je suppose que les clients externes/non approuvés ne passent pas ce proxy).

Si ce n'est pas acceptable, vous êtes de retour à d'autres méthodes d'authentification. Plutôt que d'exiger une connexion de connexion ou VPN, vous pouvez envisager un certificat de cookie ou de client permanent et ne donner que ceux-ci aux clients internes, mais vous aurez besoin d'un moyen de les livrer au client. Vous pourriez certainement livrer un cookie permanent basé sur une connexion unique.Les cookies peuvent être usurpés d'une manière similaire en ce sens que UserHostName peut être une meilleure opportunité de créer une valeur de cookie qui soit moins difficile à deviner qu'un nom de domaine.