我有一个Web应用程序,对于内部用户而言,其行为应该与外部用户不同。 Web应用程序可通过Internet获得,因此对内部用户也很明显。
所有用户都是匿名的,未经过身份验证,但内部用户的页面呈现方式与外部用户不同。我在代码中所做的是使用Request.UserHostName
然后使用Dns.GetHostEntry
。然后将结果与我web.config
中的设置(包含*.mydomain.local
之类的设置)进行比较。如果比较给出了肯定的结果,那么我呈现内部用户应该看到的HTML,否则我呈现外部用户应该看到的HTML。
但是,我的问题是我并不总是从Request.UserHostName
获得预期值。在开发网站上,我得到运行浏览器的机器的IP-number
(?),但在客户网站上我没有得到用户机器的IP-number
,我得到了其他IP-number
}。浏览器没有设置任何代理或类似的东西。
我应该使用的不是Request.UserHostName
吗?
答案 0 :(得分:3)
我也建议使用IP地址。我正在处理这种完全相同的情况,现在也建立一个认证系统,Epso和Robin M描述的条件正是发生的事情。来到站点的外部用户向我提供他们的实际IP地址,而所有内部用户都将网关机器(路由器)的IP提供给Web服务器所在的私有子网。
为了解决这个问题,我只检查那个IP。如果我获得网关的IP,我提供内部访问。如果我得到任何其他东西他们得到外部的,在我的情况下需要额外的身份验证。在你的,它只是意味着一个不同的界面。
答案 1 :(得分:2)
尝试Request.UserHostAddress,它返回客户端的IP地址。假设您的内部网络使用为LAN保留的IP地址,检查IP是内部还是外部应该相对简单。
答案 2 :(得分:0)
可能有防火墙正在进行某种NAT,以使内部客户端能够使用外部DNS名称来访问服务器。
您在客户站点上获得的IP号码是否与外部客户服务器IP相同?在这种情况下,您可以硬编码该IP地址。该防火墙后面的所有内部计算机似乎都具有相同的IP地址,您可以将它们归类为“内部”。
答案 3 :(得分:0)
看起来您正在返回面向公众的IP地址。让用户转到http://www.myipaddress.com。如果这与返回给您的软件的IP地址相同,那么绝对是这种情况。
我能看到解决这个问题的唯一方法是让他们通过VPN连接到持有asp.net应用程序的机器,或者使用其他类型的身份验证。后者可能是最好的选择。
答案 4 :(得分:0)
听起来好像用户和客户站点上的服务器之间存在代理(不需要在浏览器中配置)。它可能是内部或外部代理,具体取决于您的网络配置。
我会避免将UserHostName用于有效身份验证,因为浏览器会根据请求提供该身份验证,并且很容易欺骗。 IP地址会更有效,因为很难在TCP / IP连接中欺骗IP地址(并保持连接)。它仍然是弱认证,但在这种情况下可能就足够了。
即使您使用的是IP地址,如果客户端和服务器之间存在NAT代理,您可能必须接受通过该代理发送的任何内容都是可信的(我假设外部/不受信任的客户端没有通过该代理代理)。
如果这是不可接受的,那么您将回到其他身份验证方法。您可以考虑永久性cookie或客户端证书,而不是要求登录或VPN连接,只将这些证书提供给内部客户端,但您需要某种方式将这些证书提供给客户端。您当然可以根据一次性登录提供永久性cookie。 Cookie可以通过类似的方式进行欺骗,因为UserHostName可以创建一个比域名更不可猜测的cookie值。