我正在使用ASP.NET表单身份验证来保证安全性并间歇性地使用配置文件重叠问题。即,当我以一个用户身份登录时,它在非常“随机”时间显示为其他人。
表单身份验证是一个简单的标准实现,使用cookie作为后续请求的验证。所以我认为不存在问题。
在检查用户的IIS日志时,我发现该请求以某种方式与其他活动用户交换,因为它似乎完全来自不同的机器,具有不同的ip和用户代理,但具有相同的经过身份验证的用户。
我想知道的是ASP.NET或IIS如何确定请求来自哪个IP?
编辑START:
以下输出是IIS日志的实际内容(如果站点名称为TestApp1,则为事件)
date time cs-method cs-uri-stem cs-uri-query cs-username c-ip sc-status time-taken
27/08/12 2:32:32 GET /TestApp1/Actions/ViolationsReferralOther/0 178004 10.1.1.24 200 187
27/08/12 2:33:29 GET /TestApp1/Content/datatables/js/datatables-fnSetFilteringDelay.js 178004 10.1.1.39 304 31
第一个请求来自IP地址 10.1.1.24 ,第二个请求来自 10.1.1.39 ,两者都记录为同一个用户。
验证码
protected void Application_AuthenticateRequest(Object sender, EventArgs e)
{
HttpCookie authCookie = HttpContext.Current.Request.Cookies[FormsAuthentication.FormsCookieName];
if (authCookie != null)
{
FormsAuthenticationTicket authTicket = FormsAuthentication.Decrypt(authCookie.Value);
if (!authTicket.Expired)
{
string[] roles = authTicket.UserData.Split(new Char[] { ',' });
if (roles == null || roles.Length == 0 || (roles.Length == 1 && roles[0] == ""))
{
FormsAuthentication.SignOut();
return;
}
GenericPrincipal userPrincipal = new GenericPrincipal(new GenericIdentity(authTicket.Name), roles);
HttpContext.Current.User = userPrincipal;
//hack as per http://www.hanselman.com/blog/SystemThreadingThreadCurrentPrincipalVsSystemWebHttpContextCurrentUserOrWhyFormsAuthenticationCanBeSubtle.aspx
System.Threading.Thread.CurrentPrincipal = HttpContext.Current.User;
}
else
{
HttpContext.Current.User = null;
}
}
}
编辑结束:
答案 0 :(得分:2)
对您的问题的简短回答是,“操作系统套接字层告诉IIS。”
答案越长,IP地址就不足以识别单个用户,因为可能有多个用户共享同一个IP地址。 Cookie识别浏览会话。如果您遇到浏览会话混乱的问题,这可能是您的应用程序代码中的问题,而不是IIS或OS套接字层中的问题(两者都非常好在现实世界中测试过。)
更新:您正在使用System.Threading.Thread.CurrentPrincipal
进行攻击,这似乎很狡猾(是的,我阅读了您链接到的Scott Hanselman的页面)。我不会这样做,除非你有一个绝对清晰的理解为什么你需要这样做以及它的含义是什么。例如,如果第二个请求由与第一个请求相同的线程处理,但第二个请求不通过相同的认证块,该怎么办?当时附加到该线程的当前主体是什么?也许它仍然与之前的请求相同。
答案 1 :(得分:0)
IIS只接受从OS网络层接收的数据包中编码的IP地址。在没有深入研究OSI模型中的所有网络层业务的情况下,ASP.NET实际上只关注底层Web服务器为其提供的IP信息,以HTTP,FTP等协议编码。 / p>
答案 2 :(得分:0)
这是一个非常晚的回复。我应该早点为社区的利益更新它。我现在正遵循的原则,而不是迟到。潜在的问题是由我之前不知道的设计引起的。
默认情况下,所有项目都由IIS 7及更高版本中的ASP.NET管道处理,其中包括静态文件,如 js 和 css 。直到IIS的另一个功能是好的,对于静态文件,它在极短的时间内内部使用一些智能缓存。但是,在我的情况下,它导致错误的配置文件被分配给错误的用户。
我从ASP.NET http管道中排除了静态文件(通过浏览文件.ext看是天真的方式),问题就消失了。