CODEWITHSUNDEEP
asp.net-mvcasp.net-mvc-2authorization
nathanchere
nathanchere

Reputation: 8098

ASP.NET MVC Authorize attribute behaves different in IE and FireFox

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?

Upvotes: 3

Views: 1648

Answers (1)

Aaronontheweb
Aaronontheweb

Reputation: 8394

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.

Upvotes: 3

Related Questions