ASP.NET MVC 授权属性在 IE 和 FireFox 中的行为不同

发布于 2024-10-07 10:48:32 字数 1542 浏览 2 评论 0原文

首先要做的事情是:这只是一个示例。这不是一个关于这是否是进行身份验证的有效方法的问题。

基本上,我遇到了奇怪的行为,这取决于所使用的浏览器。在 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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

陌伤浅笑 2024-10-14 10:48:32

我使用几种不同的方法测试了您的 Uri 路由方案,并消除了这个问题。这在两种浏览器中效果相同。我对这类事情非常偏执。

因此,我倾向于认为两个浏览器实例之间的 cookie 行为或状态有所不同。尝试以下操作:

  1. 尝试使用 IE8 / IE9 中的 InPrivate 会话对您的表单进行授权 - 这是一个无 cookie 会话,应该会因正常的失败后路由行为而失败。我们试图通过此测试消除您的 IE 会话中存在脏 cookie 而 Firefox 中存在干净 cookie 的可能性。如果此测试成功,请继续执行步骤 2。如果失败,请参阅步骤 3。
  2. 尝试使用标准 IE 实例对您的控制器进行授权;如果失败,请擦除所有 cookie,然后重试。如果失败,请参见步骤3。
  3. 如果这两个测试都失败,那么我们需要检查Firefox和IE中的cookie是否相同。您可以尝试使用 http://ncookiereader.sourceforge.net/ 之类的内容来比较您网站发出的 Cookie Firefox 和 IE,但打开 cookie 集合并在 Notepad++ 中比较它们可能会更简单。您的 cookie 内容将被加密,并且它们可能包含不同的身份验证票证,大概是因为您在两个不同的 IIS 会话上运行,因此为了让生活更轻松仅用于调试目的,我建议启用解密,如下所示一个选项,以便您可以在 Web.config 中使用此代码段以纯文本形式查看 Cookie:
    <表单loginUrl =“~/Account/LogOn”超时=“2880”保护=“无”/>
    - 如果您的 cookie 内容除了身份验证票之外有显着差异,请转至 http:// /aaronstannard.com/ 并通过联系表向我发送电子邮件。如果 cookie 的内容相同,请继续执行步骤 4。
  4. 此时,我将开始在授权过滤器中查找未处理的异常,并使用 Wireshark 来查看 IE 和 Firefox 发送的 HTTP 请求是否存在差异任何主要方式。如果您有任何发现,请告诉我们。

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:

  1. Try to authorize against your form using an InPrivate session in IE8 / IE9 - this is a cookieless session and should fail with normal post-fail routing behavior. What we're trying to eliminate with this test is the possibility that you have dirty cookies in your IE session and clean ones in Firefox. If this test succeeds, proceed to step 2. If it fails, see step 3.
  2. Try to authorize against your controller using your standard IE instance; if it fails, wipe all of your cookies and try again. If it fails, see step 3.
  3. If both of these tests have failed, then we need to check if the cookies in Firefox and IE are equivalent. You can try using something like http://ncookiereader.sourceforge.net/ to compare the cookies your site issues in Firefox and IE, but it might be simpler just to open up the cookies collection and diff them in Notepad++. The contents of your cookie are going to be encrypted and they might include different authentication tickets presumably because you're running on two different IIS sessions, so to make life easier for debugging purposes only I recommend enabling decryption as an option so you can view your cookies in plaintext using this snippet in your Web.config: <authentication mode="Forms">
    <forms loginUrl="~/Account/LogOn" timeout="2880" protection="None" />
    </authentication>
    - 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.
  4. At this point, I'd start looking for unhandlded exceptions in your authorization filter and I'd use Wireshark to see if the HTTP requests being sent by IE and Firefox differ in any major way. Let us know if you find anything.
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文