Why would User.IsInRole return true, but AuthorizeAttribute not?

Question

I'm securing an ASP.NET MVC 2 application, and I have a user who is in the role "Foo".

This is true:

User.IsInRole("Foo")

But yet, when I attempt to lock down a controller action like the following, the user is denied:

[Authorize(Roles = "Foo")]
public ActionResult PrivatePage()
{
    return View();
}

If IsInRole reports true, why would the Authorize attribute not allow the user in?

Do you have another [Authorize] attribute, perhaps on the controller type itself? — Levi, Feb 02 '11 at 07:49

score 3 · Accepted Answer · answered Mar 11 '11 at 05:37

3

It could be caused if you are storing persistent cookies for your forms authentication cookie. In that scenario IsInRole may check against the cookie without verifying up to date login.

answered Mar 11 '11 at 05:37

John Weldon

39,849
11
94
127

score 1 · Answer 2 · edited May 23 '17 at 12:23

For future people with a similar problem - it could depend on how you are actually setting up your roles on the current user.

I had a similar issue where the roles were being pulled out of the cookie in an override of OnActionExecuting in a base controller. Turns out this was executing after the [Authorize] attribute, so the roles weren't actually set up when the attribute was checking for them. The call to User.IsInRole, being in the View, was executing after OnActionExecuting, so it saw the roles fine.

So User.IsInRole returned what I expected, but the [Authorize] attribute did not.

I was able to resolve this by moving the code for getting the roles into a more sensible place, that executes before the Authorize attribute - for example, in Global.asax.cs:

protected void Application_AuthenticateRequest(Object sender, EventArgs e)
{
    // do stuff in here
}

Or even better, in your own custom attribute - see https://stackoverflow.com/a/5314736/206297.

score -1 · Answer 3 · answered Jan 25 '11 at 22:26

-1

They should both return true. Have you tried using SQL Profiler to check the queries run against the DB?

answered Jan 25 '11 at 22:26

Simon Hazelton

1,245
10
13

There is no database involved here. This is entirely in-memory. – dreadwail Jan 25 '11 at 22:38
What are you using for membership and role providers? The default set up is still to use sql express (I believe). If you haven't changed anything, you should be able to look at the sql express database. If you are using the test providers that was with one of the project templates for mvc 2, you should be able to put some breakpoints or System.Diagnostic.Debug.WriteLine() calls in there. – Jason Haley Jan 26 '11 at 00:46
IPrincipal != SQL provider. You and Simon appear to be under that impression, but IPrincipal (User in this case) really isn't coupled to membership or role providers. You can instantiate a principal object and manipulate it programatically in memory, which is what I'm doing here. – dreadwail Feb 04 '11 at 03:33
To further clarify, I can go "httpContext.User = Thread.CurrentPrincipal = new GenericPrincipal();" and have the code in the question operate on it, with no role or membership providers coming into play. – dreadwail Feb 04 '11 at 03:33

Why would User.IsInRole return true, but AuthorizeAttribute not?

3 Answers3

Linked