Get Help:Ask a Question in our Forums|Report a Bug|More Help Resources
Last post Oct 15, 2009 03:42 PM by jmedia
Feb 09, 2009 01:35 PM|LINK
Hello, I am a bit confused about the Authorize filter and what it exactly does.
What I understood is that:
What I fail to understand is:
The fact is that I am used to read the cookie in the Global.asax AuthenticateRequest method, if present create an instance of a custom implementation of IIdentity with an IPrincipal inside, set it to the current HttpContext.User so it can be read and used
during the current request.
But I just saw an application that does not do this step, and still works.
Anyone can give me a detailed explanation of how the Authorize filter works? Thanks.
Feb 09, 2009 05:51 PM|LINK
The three steps you listed above are pretty much the extent of [Authorize]'s logic. The [Authorize] filter is agnostic as to the underlying authentication mechanism; it can be used with FormsAuth, Windows Auth, etc. In the normal course of ASP.NET request
handling, the authentication module runs very early in the request lifecycle. The authentication module is responsible for setting HttpContext.User. In the case of FormsAuth, the authentication module sets HttpContext.User by reading the current authorization
Since MVC simply rides on top of existing ASP.NET infrastructure, this means that the authentication module has already executed by the time the MVC code is called into. We just assume that HttpContext.User has been set appropriately by that module.
Feb 10, 2009 08:26 AM|LINK
Ok then, I have one more question. Since the FormsAuth cookie does not provide a way to store user roles, I assume the Authorize Filter does not manage a scenario where it has to set the roles in the HttpContext.User. So, If I am using roles, Do I still
have to set the HttpContext.User in the global.asax?
Feb 10, 2009 10:50 AM|LINK
If you are using standard role-managing, so using configuration/roleManager element in your
web.config, then you have to specify cacheRolesInCookie="true" on this element. This enables caching roles into cookie (it's different cookie then the cookie used by forms-authentication module) - default value is
You don't have to set HttpContext.User in your global.asax.cs - it's done automatically in
Feb 10, 2009 11:33 AM|LINK
I see.. but my role management structure is a bit more complex. I have a Roles table, a Groups table and a Users table. The mappings are:
Users +-------+ Groups
Users +-------+ Roles
Groups +-----+ Roles
(where + means many)
So a User's roles are defined by all the roles applied directly to the user, plus all the roles inherited by all the groups the user belongs to. So I think I have really to do the operation in the global.asax, or do I still have hope to avoid that?
Feb 10, 2009 11:41 AM|LINK
I'm now using very similar scenario. I wrote my own implementation of RoleProvider that works with my DB. Then you must specify your role-provider class in
web.config only. It's all.
Feb 11, 2009 09:15 AM|LINK
Thank you that helped a lot. I think I need to study asp.net Membership a little harder.
Feb 11, 2009 09:28 AM|LINK
If you will write own Member-, Role and/or Profile- Providers that work against your custom database then "Simple SQL Providers" from this project can be good starting point for you:
It helped me a lot...
Feb 24, 2009 09:34 PM|LINK
Sorry to jump in on this, but i have been struggling with this of a few days now.
Augi, you mention that if you are using the standard role managing, I assume you are talking about RoleProvider.
I am not using any of the Membership Provider APIs, so I take it I still have to set the current user in global.asax in the AuthenticateRequest?
In that case, if we are just using the "Authorize" attribute (not the locations in web.config), when does the Authenticate_Request get fired?
Oct 13, 2009 02:02 PM|LINK
I've been wondering the same thing myself. I'm not using any of the Membership APIs and don't really want to but I'm not sure where I should be setting the details for the HttpContext.User, should I be doing this on by overriding the AuthorizeCore method
in my own attirbute.
I have seen references where people do it in the globax.asax but this can't be right as there will be pages within the site where you don't have to be authorised.
In previous systems we have built we have simply created a base class for our pages that inherited from the Page class and then set the HttpContext.User details in there (from either the cache or the db)
Any input would be greatly appreciated.