问题
I am essentially doing is this. However, whenever I use the built in AuthorizeAttribute, the MVC framework (I'm guessing) never looks at my principal to determine if the user has the proper roles. It keeps trying to create a new MDF file in the app_data directory, and because it doesn't have privileged it blows up.
Is this expected behavior, and should I derive my own AuthorizeAttribute and check the principal myself?
Another weird behavior to point out is that I have two sites on the same domain for which I'm doing single sign on. On either site, I'm using the same class library to recreate my custom principal on AuthenticateRequest, and I see when debugging that the principal is getting set correctly on each site. However, site 1 (the one which authenticates to the user) uses the built-in AuthorizeAttribute, and it works perfectly, but site 2, is trying to create an MDF file when any action that has the AuthorizeAttribute is called.
回答1:
Ok, I figured it out, I had to add this to my web config under system.webServer. This removes the HttpModule that replaces my principal.
<modules runAllManagedModulesForAllRequests="true">
<remove name="RoleManager" />
</modules>
回答2:
By default, a new MVC3 application uses the SqlMembershipProvider as the default authorization mechanism, and tries to store the details in a SQL Express db (MDF file).
So try clearing that in the web.config:
<membership>
<providers>
<clear />
</providers>
</membership>
As long as you are implementing all the security objects correctly (IPrincipal, IIdentity), and decryping the forms authentication ticket on Application_AuthenticateRequest, the built-in [Authorize(Roles="RoleName")] should work for you.
In that link you posted, that is essentialy what we are doing, and it works great.
来源：https://stackoverflow.com/questions/23959761/mvc-5-asp-net-identity-authorize-attribute-error