ASP.NET MVC 授权属性在 IE 和 FireFox 中的行为不同
首先要做的事情是:这只是一个示例。这不是一个关于这是否是进行身份验证的有效方法的问题。
基本上,我遇到了奇怪的行为,这取决于所使用的浏览器。在 Firefox 中,一切都按预期运行,但在 IE 上,即使授权失败,相关的控制器操作仍然会触发。
我设置了一个 ASP.NET MVC 测试站点,其中 SecureController 类继承自标准 Controller 类,并具有以下相关代码:
[AuthorizeByToken]
public class SecureController : Contrller
protected override void OnAuthorization(AuthorizationContext filterContext)
{
// Check for presence of encoded session string
if (filterContext == null) throw new ArgumentNullException("filterContext null");
if (filterContext.HttpContext == null) throw new ArgumentNullException("httpContext null");
if (filterContext.HttpContext.Request["TestToken"] == null) return;
// Complete authorization
FormsAuthentication.SetAuthCookie(csmSession.CSMUser.userName, true);
base.OnAuthorization(filterContext);
}
还有一个基于 AuthorizeAttribute 的 AuthorizeByTokenAttribute 属性,如下所示:
public class AuthorizeByTokenAttribute : AuthorizeAttribute
{
protected override void HandleUnauthorizedRequest(AuthorizationContext filterContext)
{
filterContext.Result = new RedirectResult("/");
filterContext.ActionDescriptor = null;
base.HandleUnauthorizedRequest(filterContext);
}
}
现在,例如,当您访问 http://testsite/TestSecureController/Index 它在 Firefox 中按预期工作。它进入授权代码,失败,然后重定向到根目录。在 IE 中,它进入授权代码,仍然失败,下一步是 TestSecureController 的 Index() 操作运行。
任何人都可以深入了解为什么这样的事情会依赖于浏览器吗?
First things first: this is only a sample. This is not a question as to whether or not this is a valid way of doing authentication.
Basically, I'm getting odd behaviour which is dependant on the browser being used. Everything works as expected in Firefox, but on IE the controller actions in question still fire even when authorisation fails.
I have an ASP.NET MVC test site set up where a SecureController class inherits from the standard Controller class with the following relevant code:
[AuthorizeByToken]
public class SecureController : Contrller
protected override void OnAuthorization(AuthorizationContext filterContext)
{
// Check for presence of encoded session string
if (filterContext == null) throw new ArgumentNullException("filterContext null");
if (filterContext.HttpContext == null) throw new ArgumentNullException("httpContext null");
if (filterContext.HttpContext.Request["TestToken"] == null) return;
// Complete authorization
FormsAuthentication.SetAuthCookie(csmSession.CSMUser.userName, true);
base.OnAuthorization(filterContext);
}
There's also an AuthorizeByTokenAttribute attribute based on AuthorizeAttribute like so:
public class AuthorizeByTokenAttribute : AuthorizeAttribute
{
protected override void HandleUnauthorizedRequest(AuthorizationContext filterContext)
{
filterContext.Result = new RedirectResult("/");
filterContext.ActionDescriptor = null;
base.HandleUnauthorizedRequest(filterContext);
}
}
Now when for example you visit http://testsite/TestSecureController/Index it works as expected in Firefox. It goes into the authorize code, fails, and redirects to the root. In IE it goes into the authorize code, still fails, and the next step is TestSecureController's Index() action running.
Can anyone offer some insight into why something like this would be browser dependant?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
我使用几种不同的方法测试了您的 Uri 路由方案,并消除了这个问题。这在两种浏览器中效果相同。我对这类事情非常偏执。
因此,我倾向于认为两个浏览器实例之间的 cookie 行为或状态有所不同。尝试以下操作:
- 如果您的 cookie 内容除了身份验证票之外有显着差异,请转至 http:// /aaronstannard.com/ 并通过联系表向我发送电子邮件。如果 cookie 的内容相同,请继续执行步骤 4。<表单loginUrl =“~/Account/LogOn”超时=“2880”保护=“无”/>
I tested your Uri routing scheme using a few different methods and eliminated that as an issue. That works equivalently across both browsers. I'm ultra-paranoid about that sort of thing.
Therefore I'm inclined to think that it's cookie-ing behavior or state that differs across your two browser instances. Try the following:
<authentication mode="Forms">
- if the contents of your cookies differ significantly other than just the auth ticket, go to http://aaronstannard.com/ and send me an email via the contact form. If the contents of your cookie are equivalent, proceed to step 4.<forms loginUrl="~/Account/LogOn" timeout="2880" protection="None" />
</authentication>